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@ A distributed computing environment in which agent processes direct their own movement through a 
computer network. Place processes provide a computing context within which agent processes are 
interpreted. An agent process controls its movement from one place process to another within the 
network by using a ticket. An agent process which moves from one place process to another transports 
definitions of classes of which objects included in the agent process are members. An agent process 
which moves from one place process to a second place process avoids unnecessary transportation of 
objects included in the agent process by substituting equivalent objects which are found in the second 
place process. An agent process sends clones of the agent process to several place processes 
simultaneously, if two clones travel along paths which are coextensive for an initial portion thereof, a 
single clone is transported along the initial portion of the paths and other clones are formed from th 
single clone, thereby avoiding transferring redundant information along communications media. Two 
agent processes, which occupy a single place process, interact by exchanging references to one 
another. The single place process ensures that neither agent process receives a reference to the other 
agent process without simultaneously giving to the other agent process a reference to the former agent 
process. Unauthorized or inadvertent excessive use of network resources by an agent process, or a 
place process, is prevented by associating with each process a permit which defines various capabilities 
and resource allowances of the process. 
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CROSS REFERENCE TO APPENDIX E, F AND G 

(copies of which have been fil d with this application and form part of US application 08/090 521 which 
was filed at th United States Patent Office on 8 July 1 993. 

Appendix E, which is incorporated herein by reference, describes the interchange of objects during the 
movement of a process through a network in one embodiment of the present invention, which is described more 
completely below. 

Appendix F, which is incorporated herein by reference, describes the transfer of data between computer 
systems interconnected via a network in one embodiment of the present invention. 

Appendix G, which is incorporated herein by reference, is a list of computer programs and related data in 
one embodiment of the present invention, which is described more completely below. 

A portion of the disclosure of this patent document contains material which is subject to copyright protec- 
tion. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or 
the patent disclosure, as it appears in the Patent and Trademark Office patent files or records, but otherwise 
15 reserves all copyright rights whatsoever. 

FIELD OF THE INVENTION 

This invention relates to a distributed computing environment and in particular, to an improved distributed 
20 computing environment wherein processes are created in an object oriented environment and direct their own 
movement throughout a computer network. 

BACKGROUND OF THE INVENTION 

2s Many different computing systems are available today, but most of these systems are built around funda- 

mental components such as those illustrated in Figure 1 . Typically, a computer system 20 includes a central 
processing unit 10 (CPU), which is connected through an input bus 11 to an input module 12 and through an 
output bus 13 to an output module 14. CPU 1 0 is also connected through data buses 15. 16 to a memory unit 

ao CPU 10 provides control and computing functions. Input and output modules 12. 14 are used to commu- 

nicate between the computer user and CPU 1 0. Input module 12 supplies information to CPU 1 0. Typical input 
devices are a keyboard and a mouse. Output module 14 displays information from central processing unit 10 
Typical output modules include video display monitors, printers, plotters and other visual display means. Input 
unit 12 and output unit 14 are frequently referred to as input/output (I/O) units. 
35 Memory unit 1 7 typically contains two general types of information, instructions and data. A computer pro- 

gram is a sequence of instructions that are executed by the computer to perform a specific function. Data in 
memory unit 17 are processed by CPU 10 in response to the instructions from a computer program which is 
executing in CPU 10. An executing computer program is called a computer process. 

Memory unit 17 typically includes mass memory 17A, sometimes called secondary memory, and main 
40 memory 17B. Main memory 17B is usually used to store at least a portfonof a program currently being executed 
by CPU 10 and data required by the program. Mass memory 17A, e.g. magnetic disk or tape, is used to store 
programs, data, or portions of either programs or data which are not needed immediately by CPU 10 or which 
cannot be accommodated in main memory 17B because of size limitations of main memory 17B. 

The operating system of a computer is a computer process which coordinates operation of CPU 10 I/O 
45 devices 12. 14 and 17A and main memory 17B and which provides an interlace between user applications 
(defined below) and computer hardware. As is used herein, the term computer hardware refers to the physical 
components of the computer system. As an operating system is necessary for the orderly operation of a com- 
puter system, the operating system is loaded into main memory 1 7B and executed during power up of the com- 
putersystem (a process called "booting") and remains in main memory 17B and in execution until the computer 
so system is ultimately deactivated. 

A user application generally refers to a computer process which executes in addition to, and is generally 
considered distinct from, the operating system. A user application begins ats m point in time as source code 
i.e., comput r instructions in a form int lligible to human b ings. This source cod is translated or "compiled" 
into object code, which is a form intelligible to computer system 20, particularly CPU 10. Sev ral object code 
ss modules may be linked to form a single xecutable image, which is in a form which can b processed by CPU 
1 0 of computer system 20. The program is executed by copying th executable imag into main mem ry 1 7B 
and instructing CPU 10 to carry out th instructions, ne by one. of the executable image. As stated above 
a computer program in such state of ex cution is called a process. 
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Th instructions xecuted by a process executing within computer system 20 generally manipulate the re- 
sources of computer system 20. For example, instructions can manipulate data stored in mass memory 1 7A, 
accept data from input module 12 or display data on output module 14. Som processes, which are designed 
to execute on a first computer system, are configured to issue computer instructions which manipulate resourc- 

5 es of a second computer system. 

It is well-known in the art of computer communications to connect two or more computer systems such 
that data can be transferred between two or more computer systems. Two or more computer systems so con- 
nected are collectively called a "network*'. In such a network, each computer system treats each other com- 
puter system as an I/O device to which data can be sent and from which data can be received. 

10 A first process executing on a first computer system can issue instructions to a second process executing 

on a second computer system. The second process then manipulates the resources of the second computer 
system in accordance with the instructions received from the first process. The second process is called a 
"server" process because the second process provides a service to the first process, which is called a "client" 
process. The service provided is the manipulation of resources of the second computer system. 

15 Many computer communication systems implement what is called "remote procedure calling". In remote 

procedure calling, a client process, which is executing on a first computer system and which seeks to manip- 
ulate data on a second computer system, requests action through a server process, which is executing on the 
second computer system and which manipulates data in response to requests from the client process. Th 
server process performs any of an inevitably finite list of operations on behalf of the client process. Often it is 

20 the case that the precise function requested by the client process is not among the particular operations per- 
formed by the server process. To perform a function for which no server process operation is defined requires 
several requests to and responses from the server process that require substantial use of communications 
media which in turn involves considerable expense and time. 

Logic flow diagram 200 (Figure 2A) illustrates an example of remote procedure calling. Logic flow diagram 

25 200 is described in the context of computer systems 20Aand 20B (Figure 2B), which are interconnected through 
network 256. Suppose a client process 252 on computer system 20A is to delete all files on computer system 
20B whose names match a given pattern, e.g., file names ending in "TMP", and which have not been modified 
in at least 30 days. Client process 252 sends to server process 254 which is executing on computer system 
20B a request to list all files in step 21 (Figure 2A). Arrow 260 (Figure 2B) represents that request Processing 

30 transfers from step 21 (Figure 2A) to step 22 in which client process 252 (Figure 2B) receives the list from 
server process 254, as shown as arrow 262. Steps 21 and 22 (Figure 2A) involve two transfers across network 
communications media. 

Double rectangles in Figures 2A and 3A indicate information transfer across network 256 (Figure 2B). 
Whereas execution of an instruction within either computer 20A or computer 20B takes between several nano- 

35 seconds to several microseconds, transfer of information across network 256 generally takes seconds or min- 
utes depending on the configuration of network 256 and on the amount of information. In some networks, trans- 
fer of a large amount of data can take an hour or more. 

Processing transfers from step 22 (Figure 2A) to for each filename step 23. For each filename step 23 
and next steps 23a, 23b and 23c define a loop within which each filename of the list of filenames is processed 

40 by the client process. For each filename of the list, processing transfers from for each filename step 23 to a 
test step 24 in which client process 252 (Figure 2B) compares the filename to a pattern. If the filename does 
not match the pattern, processing transfers from test step 24 (Figure 2A) through next step 23a to for each 
filename step 23 and the next filename is processed. 

Conversely, if the filename matches the pattern, processing transfers from test step 24 to step 25. In step 

45 25, client process 252 (Figure 2B) sends to server process 254 an instruction to provide the date that the par- 
ticular file was last modified as shown by arrow 264. Processing transfers from step 25 (Figure 2A) to step 26 
in which client process 252 (Figure 2B) receives from server process 254 the date requested as represented 
by arrow 266. Steps 25 and 26 (Figure 2A) involve two more transfers across network communications media 
for each such matching filename. 

so Processing transfers from step 26 to a second test step 27 in which client process 252 (Figure 2B) com- 

pares the date received with the current date less 30 days. If the date indicates that the file has been modified 
within the preceding 30 days, processing transfers from s cond test step 27 (Figure 2A) through next step 23b 
to for each filename test step 23 in which th next f ilenam is processed. Conversely, if the dat indicates 
that the file has not b en modified within the preceding 30 days, processing transfers from sec nd test step 

55 27 to step 28. 

In step 28, client process 252 (Figure 2B) sends to server process 254 an instruct! n directing server proc- 
ess 254 to delete th file from computer system 20B as represented by arrow 268. Processing transfers from 
step 28 to step 29 (Figure 2A), in which dient process 252 (Figure 2B) receives from s rver process 254 ac- 
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knowledgement of the deletion as represented by arrow 270. Thus, steps 28 and 29 (Figure 2A) invdv two 
further transfers across network 256 (Figure 2B) for ach file to be deleted. 

Processing transfers from step 29 through next step 23C to for each filename st p 23. If all filenames in 
the list have been processed, processing transfers from for each filename step 23 to terminal step 20b in which 
processing terminates. Thus, processing according to logic flow diagram 200 (Figure 2A) requires a multitude 
of information transfers across network 256. Such heavy use of network communications media is both costly 
and time consuming. 

An alternative approach to remote procedure calling is "remote programming 0 . In remote programming, a 
process, which is called a "client process 0 and which executes on a first computer system, sends to a server 
process executing on the second computer system a list of instructions. The instructions are then carried out 
by the server process effectuating the goal of the client process. The instructions which the server process 
is designed to carry out must have some degree of generality; i.e., the instructions must provide some degree 
of decision-making capabilities. 

Logic flow diagram 300 (Figure 3A) illustrates an example of remote programming. To effectuate the ex- 
ample given above with respect to Figures 2A and 2B in a remote programming environment, client process 
352 (Figure 3B) in step 31 (Figure 3A) builds a program whose instructions are represented by logic flow di- 
agram 31 -P. Logic flow diagram 31 -P is described below. 

Processing transfers from step 31 to step 32, in which the program is transferred to computer 30B (Figure 
3B) through network 356 as represented by arrow 358. Processing transfers from step 32 to step 33 (Figure 
3A) in which the program is executed within computer 30B. During execution, the program is process 352A 
(Figure 3B) within computer 30B. The instructions of program 352A are executed according to logic flow dia- 
gram 300. 

In step 31-B (Figure 3A), a list of filenames is created. Processing transfers from step 31 -B to for each 
filename step 31-C. For each filename step 31-C and next steps 31-H, 31-1, and 31-J form a loop within which 
each filename in the list of filenames is processed. For each filename, processing transfers from for each fi- 
lename step 31-C to test step 31-D in which the filename is compared to a pattern. If the filename does not 
match the pattern, processing transfers from test step 31-D through next step 31-H to for each step 31-C. Con- 
versely, if the filename matches the pattern, processing transfers from test step 31-D to step 31 -E. 

In step 31-E, process 352A retrieves the date of last modification of the file having the filename. Proc- 
essing transfers from step 31-E to a second test step 31 -F in which the date is compared to the current dat 
less 30 days. The date of last modification of the file is retrieved from server process 354 (Figure 3B). If th 
date of last modification is more recent than the date of 30 days prior, processing transfers from second test 
step 31-F (Figure 3A) through next step 31-1 to for each filename step 31-C. Conversely, if the date of last 
modification is prior to the date of 30 days prior, processing transfers from second test step 31-F to step 31- 
G. In step 31-G, the file is deleted by issuing an appropriate instruction to server process 354 (Figure 3B). 
Processing transfers from step 31-G (Figure 3A) through next step 31-J to for each filename step 31-C. If all 
filenames in the list have been processed, processing transfers from for each filename step 31-C to terminal 
step 31 -K in which process 352A terminates. As indicated by arrows 360 (Figure 3B), all interaction between 
process 352A and server process 354 transpired entirely within computer 30B without use of network 356. 

After successful completion of the program, processing transfers from step 33 to step 34 (Figure 3A) in 
which server process 354 (Figure 3B) reports to client process 352 that the program completed successfully 
as represented by arrow 362. Note that this remote programming procedure involves only two uses of network 
communications media: a first to send the program or list of instructions to server process 354 as represented 
by arrow 358 and a second to receive from server process 354 notification of successful completion of the 
program as represented by arrow 362. Note also that client process 352 was able to request of server process 
354 an operation not explicitly provided by, and perhaps not even anticipated by the developers of, server proc- 
ess 354. 

However, remote programming encounters the same inefficiencies of remote procedure calling when a 
computer process seeks to coordinate manipulation of data on two or more computer systems. For example, 
a process on computer X may seek to delete all files on computer system Y or computer system 2 which have 
the same name, date of last modification and size as any file on computer X. Since server process 354 de- 
scribed above with respect to Figures 3A and 3B is capab) of directly manipulating resources on the computer 
system on which th serv r process is ex cuting, i.e. computer system Y, the server process is unable to co- 
ordinate data management spanning more than one computer system without producing the inefficiencies dis- 
ss cussed abov in conjunction with remote process calling. 

An improvement over rem t programming is described by C. Daniel Wolfeon, etal. ( "Intelligent R uters", 
9th International Confer ence on Distributed Computing Systems at pp. 371-375 (1989). Wolfeon et al. disclosed 
a system wherein a process could move from on computer system to another within a network. The process 



45 



50 



BNSDOCID: <EP OS3471QA5> I > 



EP 0 634 719 A2 

dir cted its own movement through the network by issuing an instruction whose execution caused th process 
to be moved. The instruction specified to which computer syst m the process was to be moved. 

However, the solution in the form disdos d in Wolfson et al. was of limited functionality. Processes were 
required to be configured to comport with the specific requirements of the computer system to which the re- 

5 spective processes moved. Processes were not able to communicate with one another; processes instead di- 
rectly stored or directly retrieved data from the mass memory of the computer system within which the respec- 
tive processes were executing. One process could only interact with another process only if both processes 
knew the precise location within mass memory where messages were to be stored and/or retrieved. 

The system disclosed by Wolfson et al. did not provide any security. Thus, to the extent that the Wolfson 

10 et al. system allowed one process to interact with another process, a malicious process could interfere with 
the execution of a second process. In addition, the set of instructions provided to processes of the system dis- 
closed by Wolfson et al. was very limited; only character string data and numerical data representing real num- 
bers were provided for. 

Another system similar to that disclosed by Wolfson et al. was that described by D. Tsichritzis et al., "KNOs: 
15 KNowledge Acquisition, Dissemination, and Manipulation Objects", ACM Trans, on Office Information Sys- 
tems, vol. 5, no. 1, pp. 96-112 (1 987). The system described by Tsichritzis et al. added to the system described 
by Wolfson et al. the generality of object-oriented programming. 

Object-oriented programming organizes data and instructions into "objects" in which data represent the 
"state" of an object and instructions are grouped into tasks or "operations" that the object can "perform". Object- 
20 oriented programming represents a very useful conceptual framework in which problems solved by a computer 
may be more easily reduced to a series of computer instructions. 

Objects created in an object-oriented environment are grouped into classes. Objects of a class have states 
of the same structure and perform the same operations. The system disclosed by Tsichritzis et al. did not pro- 
vide for the mobility of class definitions; therefore, objects of a given class created within the environment de- 
25 scribed by Tsichritzis et al. could only travel to those computer systems for which the given class was defined. 
Additionally, objects in the environment described by Tsichritzis et al. were represented in a form that required ; 
that the computer systems of the network, within which objects could travel, were homogeneous. 

The system taught by Tsichritzis et al. further described an instruction by which a first process, i.e., a "head" 
process, could create copies of itself. The copies were called "limbs". Tsichritzis et al. taught that limbs could 
30 be sent to remote computer systems at the direction of the head process. However, the limbs were not activ ; > 
the computer instructions of a limb were executed only at the direction of the head process. Directing the ac- 
tivity of a limb process positioned in a remote computer system required that the head process issue commands 
to the limbs across network communications media, involving considerable time and expense in large net- 
works. 

35 Further inefficiencies were found in the system taught by Tsichritzis et al. when a small computer, e.g., a 

personal computer, was connected to a large network through a large computer, e.g., a mainframe computer. 
For example, to send many limbs to various computers of the network, the small computer was required to 
send many identical limbs between the small computer and the large computer. As limbs, which are copies of 
the head process, could be quite large, inefficiencies in such a system could have been quite substantial. 

40 Tsichritzis et al. taught a system wherein a first process communicated with a second processes by giving 

to the second process a reference to the first process. A reference is data which identifies an object and which 
grants access to the object identified. As the second process contained a reference to the first process, the 
second process could request that the first process execute specific computer instructions which were con- 
tained within the first process. However, as the first process provided the second process with a reference to 

45 the first process without simultaneously obtaining a reference to the second process, the second process had 
access to the first process and the first process did not have reciprocal access to the second process. Such 
a system permitted a "malicious" process, i.e., a process designed by a malicious programmer or inadvertently 
designed to harm other processes, to gain access to a second process without granting reciprocal access. 
Thus, in spite of the achievements of Wolfson et al. and Tsichristzis et al., neither discloses a system in 

so which new classes of objects and processes can be created and can be transported to and processed by com- 
puter systems within the network which do not contain class definitions for the new classes. Neither does either 
W Ifson et al. or Tsichristzis et al. disclose a mechanism for implementing a complex and hierarchical security 
scheme. Furthermore, neither Wolfson et al. nor Tsichristzis et al. disclose computer processes which can in- 
teract with one another but which cannot gain access to oth r processes without granting reciprocal access. 

55 Furthermore, neither Wolfson et al. nor Tsichristzis et al. disclose computer processes which can travel to 

several computer systems simultaneously by creating several autonomous clones f a process and transport- 
ing the clones to respectiv computer systems. The limbs taught by Tsichristzis t al. are not autonomous as 
the computer process controls the actions of limbs at remote computer systems. Furthermore, neither W Ifson 
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et al. nor Tsichristzis t al. disclose efficient transportation of the clones to the resp ctive computer systems 
in which transportation of redundant information across network communication media is minimized. 

SUMMARY OF THE INVENTION 

According to the principles of this invention, a set of interpreted, object-oriented computer instructions is 
used to create novel computer processes that are executed in a distributed computer system. A particular proc- 
ess that utilizes the set of computer instructions is activated by an engine that is executing within the distributed 
computer system. The engine interprets and effectuates the instructions of the particular process within the 
distributed computer system. 

Each engine in the distributed computer system interprets the instructions that define a process uniformly. 
In other words, the instructions which comprise a process and which are interpreted by a first engine do not 
depend on the particular configuration of the computer system within which the first engine is executing. The 
instructions, therefore, can be moved to and interpreted by a second engine, even if the first and second en- 
gines are executing within two separate computer systems whose operating systems and hardware are other- 
wise generally incompatible. The interpreted instructions are implemented by using interfaces to communica- 
tion, storage, computing and other subsystems of the computer system within which the engine is executing. 
These interfaces, which collectively form part of one embodiment of the present invention, are described in 
Appendix C, which is a part of this disclosure and is incorporated in its entirety herein by reference. 

Two or more engines are interconnected to form a network. The network is a universe within which com- 
puter processes of this invention travel. In one embodiment, the network encompasses computer systems that 
would normally be considered clients of, and not part of, other networks. For example, one embodiment of the 
network of this invention encompasses the workstations which are connected by the network. The term "work- 
station" is used herein to describe a computer system which is used for purposes other than the transportation 
of information to other computer systems. The engines of this invention are interconnected so that engines 
are capable of moving computer processes among themselves. 

To transport a particular computer process, the computer process is suspended and the execution state 
of the computer process is preserved. The instructions of the computer process, the preserved execution state, 
and objects owned by the computer process are packaged, or "encoded", to generate a string of data that is 
configured so that the string of data can be transported by all standard means of communication used to form 
a network. In one embodiment, the string of data is transported between engines as specified by the protocol 
described in Appendix D, which is a part of this disclosure and is incorporated herein in its entirety by reference. 

Once transported to a destination computer system of the network, the string of data is decoded to gen- 
erate a computer process within the destination computer system. The decoded computer process includes 
those objects encoded as described above and has the preserved execution state. The destination computer 
system resumes execution of the computer process. The instructions of the computer process are executed 
by the destination computer system to perform complex operations, including defining, creating and manipu- 
lating data objects and interacting with other computer processes executed by the destination computer sys- 
tem. As computer processes are uniformly interpretted throughout the network and are encoded and decoded 
for transport between computer systems, the computer processes of this invention provide a new level of func- 
tionality and versatility in intercomputer communication. 

In one embodiment, two classes built into the set of computer instructions of this invention are an agent 
class and a place class. Instructions formed using the agent class are interpreted by an engine to form an "agent 
process", sometimes referred to herein simply as "an agent". An agent is an active object in that an engine 
initiates execution of an agent upon creation of the agent The agent class provides instructions which enable 
an agent to (i) examine and modify itself, (ii) transport itself from a first place process, which is described more 
completely below, in the network to a second place process in the network, and (iii) interact with other agents 
found at the second place process. The first and second place processes can execute within two separate com- 
puter systems of the network. Thus, an agent can travel from a first computer system to a second computer 
system. 

An agent can contain information which is carried with the agent from the first place process to the second 
place process. Additionally, the extensibility, generality and functionality of the set of computer instructions 
discussed more compl t ly below provide trem ndous flexibility and control in determining, according to the 
instructions which compris an agent, how and to what destination th agent, and the information contained 
therein, trav Is. 

Th power f ag nts is counterbalanced by "permits". A permit limits the particular capabilities of a par- 
ticular agent on particular occasions. The permit of an ag nt specifies which of several of the operations de- 
fined for the agent class can or cannot be performed by the agent. The p rmit further limits the amount of 
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processing resources the agent can consume and the tim at which the agent expires. Additionally, the permit 
specifies th priority of execution of th agent relative to other agents. 

Instructions form d using the place class are interpreted by an ngine to form a "place process", some- 
times referred to herein simply as °a place". A place is also an active object and the place class provides in- 
5 structions which enable a place to examine and modify itself and to serve as a venue for agents and a context 
in which agents can interact. Agents each occupy a respective single place. Additionally, each place can oc- 
cupy a single other place. 

Places provide a degree of privacy and security for agents. For example, an agent, which is configured t 
avoid contact with other agents, can occupy a place which is not generally known to other agents, or which 
10 denies ingress to other agents. Conversely, an agent, which is configured to provide services publicly to a large 
number of agents, can occupy a place which is widely known to other agents and which grants ingress to other 
agents. 

Agents cannot interact at a distance; i.e., no two agents can interact unless both occupy the same place. 
To interact with a second agent occupying a second place, a first agent, which occupies a first place, issues 
15 a command causing the first agent to be transported to the second place as discussed below with respect to 
the "go" operation. While both the first and second agents occupy the second place, the first agent can interact 
with the second agent 

Thus, the processes of this invention are a novel implementation of "remote programming," and not the 
more familiar "remote procedure calling" paradigm. Remote programming improves upon remote procedure 

20 calling by (i) enabling processes to interact without communicating across network communications media and 
(ii) improving the performance of the interactions between processes by eliminating communication across 
network communications media which often has high-latency. 

The movement of an agent process, from a first place process in a first computer system to a second place 
process either in the first computer system or in a second computer system is called a trip. The agent initiates 

25 the trip by using a "go" operation, which is defined in the agent class. The agent controls the movement either 
through the network or within the computer system by creating and submitting, as an argument to the "go" 
operation, a ticket which defines the trip. In one embodiment, the ticket specifies the place to which the agent 
is to travel, the "way" by which the agent is to travel, the amount of time in which the trip must be completed, 
and an indication of the urgency of the trip, i.e., the priority of the trip relative to other trips by other agents 

30 that may be concurrently scheduled. 

The ticket can identify the destination place by specifying the address, name, class or any combination 
of the address, name and class of a place to which the agent is to travel. The destination of the trip is any ' 
place of the specified address, name and/or class which grants the agent ingress within the time permitted 
by the ticket 

35 In the "go" operation, the agent is moved from a first place to a second place as follows: (i) the agent is 

suspended and the execution state of the first agent is preserved; (ii) the agent is represented in a standardized 
form, i.e., an octet string, which includes representation of the agent's preserved execution state; (iii) the stan- 
dardized form is transported from the first place to the second place, potentially involving the transfer of th 
standard form from a first computer to a second computer; (iv) the agent at the second place is formed from 

40 the standardized form, including the execution state represented in the standardized form; and (v) interpretation 
of the agent is resumed, the agent initially having the execution state represented in the standardized form. 

As mentioned above, the set of computer instructions of the present invention is object-oriented. Therefore, 
all objects formed according to the present invention are organized into classes. All classes in the present in- 
vention are represented by data objects which can be moved along with an agent Thus, classes, which are 

45 not defined within a place, can nevertheless be used by an agent travelling to the place simply by the agent 
defining the classes and transporting the corresponding class objects to the place. 

Every object in one embodiment of the present invention is owned by a process, i.e„ either an agent or a 
place. When an agent travels from a first place to a second place, all objects owned by the agent are effectively 
moved to the second place along with the agent However, as discussed below, objects which are equivalent 

so to objects already occupying the second place are not transported in one embodiment of the present invention. 
In addition to the objects owned by the agent, all class objects defining classes of which those objects are 
members are moved along with the agent to the second place. A class object is an object constructed in ac- 
cordance with the set of computer instructions described below and in Appendix A which represents a class 
of objects. 

55 Thus, if an object owned by an agent travelling to a second place is a member of a class not defined in 

the second place, the object can still travel with the agent as the agent also carries to the second place class 
objects defining the classes of which th bject is a member. In the prior art, a process which trav lied from 
a first computer to a sec nd computer could only process data objects which belonged to class s defined on 
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the second computer. Class definitions wer not typically transported with migrating processes in the prior art. 
As new classes can be formed within a first place and members of those n w classes are f re to trav I to other 
places for which thos new classes are not d fined, the present invention provides agents a I vel of extensi- 
bility, mobility and generality not found in the prior art 

5 In the present invention, many classes of objects are defined at multiple places and therefore do not need 

to be moved to such places. Class objects and any other objects, which are likely to be found at many places 
are made interchangeable in one embodiment of the present invention. 

Interchangeable objects each have a digest. An interchangeable object, which is owned by an agent that 
is travelling from a first place to a second place, does not travel with the agent. Rather, the digest of the in- 
to terchangeable object is moved with the agent to the second place. When the agent arrives at the second place, 
interchangeable objects in the computer system which contains the second place are examined to determine 
whether any of the interchangeable objects has a digest equal to the digest transported with the agent. If such 
an interchangeable object is found in the computer system which contains the second place, the interchange- 
able object is substituted for the interchangeable object, which was left behind at the first place. 

is If, however, no such interchangeable object is found at the second place, the interchangeable object left 

behind at the first place is moved to the second place. In this way, the movement of objects across network 
communications media is avoided when equivalent objects are present at the destination place. In particular, 
as class objects are interchangeable, an agent travelling to a second place causes the movement to the second 
place of only those class objects defining classes which are not defined within the second place. Avoiding un- 

20 necessary movement of class objects through the network makes practical the movement of objects owned 
by an agent to places which contain no definition of one or more classes to which those objects belong. 

In one embodiment of the present invention, classes are identified by citations. In a computer network 
having many computer systems supplied by different vendors, various versions of the disclosed instruction 
set can be implemented on various computer systems to which and from which agent processes can travel. A 

25 citation is an object which is used to identify classes or objects which are forward-or backward-compatible 
with one another. Therefore, an instruction requiring use of an object of a first class, or the first class itself, 
can use an object of a second class, or the second class itself, depending on the particular requirements of 
the instruction, if the second class is backward-compatible with the first class. 

An agent, occupying a first place, is also capable of creating one or more clones of the agent and moving 

30 each clone to a respective place. A clone is an agent process which is the result of duplicating an existing agent 
process. An agent initiates and controls the creation of one or more clones, and the movement of each clone 
to a respective place process by performance of operation "send." The agent specifies the number of clones 
to be created and defines the corresponding trips by creating one or more tickets which are supplied as argu- 
ments to operation "send". Each ticket defines a trip to be taken by a respective clone of the agent. The numb r 

35 of tickets supplied by the agent defines the number of clones created. 

Once a clone of the agent is moved to a second place, the clone initially has the execution state of the 
agent at the time the clone was created. Thus, when the clone arrives at a second place, the clone continues 
to execute so as to simulate the movement of the agent to the second place as described above with respect 
to operation "go." 

40 in the prior art, a first process, i.e., a head process, created limb processes which had the same interface, 

i.e., could generally perform the same operations, as the head process. Limb processes did not act except as 
directed by the head process and could move to remote computer systems only at the direction of the head 
process. 

In the present invention, however, a clone is autonomous and is not controlled by the agent which created 
45 the clone. For example, the clone can be configured to ignore all attempts by the agent to arrange a meeting, 
which is discussed below, whereby the agent and the clone can interact. The agent must attempt to interact 
with a clone of the agent in the same way the agent attempts to interact with any other agent, as discussed 
below. As the clone is autonomous, the clone occupying the second place can travel to a third place by per- 
formance of operation "go" without being so instructed by the agent and even without the consent of the agent. 
so As limb processes of the prior art were not active and acted only at the direction of a head process, the 

head process and a remote limb process necessarily interacted across network communications media. The 
paradigm of this prior art system is therefore more clos ly relat d to remote procedure calling. In contrast, 
clones of ag nts formed in accordanc with the present inventi n are active and aut nomous and embody all 
of the instructions which form the ag nt. Therefore, no interaction is required (in fact, no interaction is allowed) 
across network communications media. Therefore, th paradigm of the present invention is more closely re- 
lated t remote programming. The present invention therefore represents a significant increase in generality 
over the prior art 

Increases in efficiency in one embodiment of the present invention are realiz d in performance fop ration 
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"send" by deferring cloning of an agent as long as possible. For example, a first clone and a second clone are 
to be sent to a first place and a s cond place, respectively. Suppose that the agent is executing within a first 
computer system, that the first place is executing within a second computer system, and that the second place 
is executing within a third computer system. Suppose further that in travelling to the first and second places, 

5 the first and second clones must travel through an engine executing on a fourth computer system. In such a 
case, a single clone is formed and transported to the engine executing within the fourth computer system. Thus, 
only a single done is created within the engine interpreting the original agent thereby saving space within that 
engine and only a single clone is transported across network communications media to the fourth computer 
system thereby saving time in transporting clones to the fourth computer system. The engine executing within 

10 the fourth computer system forms from the single clone the first and second clones and transports the first 
and second clones to the first and second places, respectively. 

As an agent can own objects which account for a substantial majority of the size of the agent, e.g., a ras- 
terized graphical image such as a facsimile transmission or digitized sound, avoiding sending several copies 
of such large objects, each copy owned by a respective clone, to a single engine saves substantial time and 

15 expense. 

A first agent, occupying a place, can initiate a meeting between the first agent and a second agent occu- 
pying the place. During such a meeting, the first agent can transfer to and receive from the second agent data 
in the form of objects, and the second agent process can transfer to and receive from the first agent data in 
the form of objects. 

20 The present invention represents a significant improvement over a prior art system which teaches the post- 

ing of messages on a virtual bulletin board by a first process. The messages are then "read" by the intended 
recipient process. In the prior art system, a first process gives to a second process a reference to the first proc- 
ess by posting the reference on the virtual bulletin board. However, since there is no mechanism for simulta- 
neous exchange of references, the second process has access to the first process before giving to the first 

25 process a reference to the second process. Thus, there is no mechanism to prevent "malicious" processes from 
gaining access to other processes without granting to the other processes access to themselves. 

The present invention represents an improved method of establishing contact between two processes 
such that a first process cannot obtain access to a second process without simultaneously granting to the sec- 
ond process access to the first process. 

30 In one embodiment of the present invention, two agents can interact only if both agents occupy the same 

place and the place is a meeting place. A meeting place is a place that is a member of a class of meeting places/ 
which is a subclass of the class of places. A first agent directs that a meeting be arranged between the first 
agent and a second agent by issuing an instruction directing the meeting place to arrange the meeting. The' 
issued instruction is called operation "meet", and the first agenfs issuance of the instruction is called "request- 

35 ing a meeting". 

The first agent supplies, as an argument to the instruction, a petition defining the meeting. The petition 
defines the meeting by specifying the second agent as the petitioned agent The second agent is specified 
by specifying the name and/or the class of the second agent. The petition further defines the meeting by spec- 
ifying the amount of time in which the meeting must be arranged or abandoned. 

40 in arranging the meeting, the meeting place supplies to the second agent the name and class of the first 

agent and indicates that the first agent has issued an instruction requesting a meeting with the second agent. 
The second agent examines the name and class of the first agent and responds to the meeting place either 
accepting or rejecting the meeting with the first agent 

If the meeting is rejected, the first agent is informed that the second agent is not available. If the meeting 

45 is accepted, the meeting place gives to the second agent a reference to the first agent and gives to the first 
agent a reference to the second agent With a reference to the second agent, the first agent (i) can direct the 
second agent to perform operations; (ii) can supply to the second agent objects as arguments; and (iii) can 
receive from the second agent objects as results. As the second agent has a reference to the first agent, the 
second agent has similar capabilities with respect to the first agent 

so Either the first or the second agent can terminate the meeting between the two by issuing an appropriate 

command. The meeting place, in performing an operation "part" in response to the issued command, voids 
any references to the second agent contained within th first agent and voids any ret rences to the first agent 
contained within the second agent, thereby terminating interaction between the two agents. 

The present invention represents a significant improvement over the prior art as a first agent cannot gain 

55 access to a second agent unless th second agent agrees or without granting to the second agent access t 
the first agent Additionally, since two agents cannot interact unless both occupy the same meeting place, in- 
termediate levels of security are available to agents. Forexampl , an agent can protect itself from other agents 
by occupying a m eting place wh s location is not widely known by other agents. Inversely, an agent, which 
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is design d to be highly visibl , may occupy a well-known m eting plac .No such m chanism is available in 
the prior art. 

BRIEF DESCRIPTION OF THE DRAWINGS 

5 

Figure 1 shows the structure of computer systems of the prior art. 

Figure 2A is a logic flow diagram of a prior art method using remote procedure calling. 

Figure 2B shows a prior art network implementing remote procedure calling. 

Figure 3A is a logic flow diagram of a prior art method using remote programming. 
10 Figure 3B shows a prior art network implementing remote programming. 

Figures 4A and 4B show the movement of an agent process through a network constructed in accordance 
with the present invention. 

Figures 5Aand 5B show processes, formed in accordance with the principles of the present invention, exe- 
cuting within a computer system. 
15 Figure 5C shows a portion of a class hierarchy graph in accordance with one embodiment of the present 

invention. 

Figures 6A-6C show the movement of an agent process through a network formed in accordance with the 
present invention. 

Figures 7A-7E show the movement of clones of an agent process through a network formed in accordance 
20 with an aspect of the present invention. 

Figures 8A-8F illustrate interaction between two agent processes by using operation "meet". 
Figures 9A-9E illustrate the interrelations of place processes formed in accordance with one aspect of the 
present invention. 

Figure 10 shows the structure of a computer network formed in accordance with the principles of the pres- 
25 ent invention. 

Figures 11 A and 11B show alternative representations of the network shown in Figure 10. 
Figure 12 is a diagram illustrating the class relationships of an agent process in one embodiment of the 
present invention. 

Figures 1 3A and 1 3B illustrate the state of an agent process formed in accordance with the present inven- 
30 Hon immediately before and after, respectively, movement of the agent process within a computer network of 
the present invention by performance of operation "go". 

Figures 14A-14G are logic flow diagrams which illustrate the steps taken to move an agent process through 
a network in accordance with the present invention by performance of operation "go". 

Figures 15A-15E show the structure of a network formed in accordance with the present invention and 
35 illustrate the movement of an agent process through the network. 

Figure 16 shows the structure of an agent process including a permit. 
Figure 1 7 shows the structure of the permit of Figure 16. 

Figure 1 8A shows the structure of the ticket of Figure 1 3A including a teleaddress, a citation, a telename, 
and a way. 

40 Figure 1 8B shows the structure of the way of Figure 1 8A. 

Figure 19 shows the structure of the telename of Figure 18A. 

Figure 20A shows a dictionary formed according to one embodiment of the present invention. 
Figure 20B shows the structure of a finder constructed according to one embodiment of the present in- 
vention. 

45 Figure 21 shows the structure of an encoded agent in accordance with one embodiment of the present 

invention. 

Figures 22A and 22B show the state of an agent process immediately prior to and following, respectively, 
performance of operation "entering". 

Figure 22C is a logic flow diagram illustrating the steps taken in performance of operation "entering" in 
so accordance with one embodiment of the present invention. 

Figures 23A and 23B show a portion of the state of a process immediately preceding and following, re- 
spectively, performance of operation "exiting". 

Figures 24A-24C are logic flow diagrams illustrating th steps taken in transporting an agent process 
through a n twork in accordance with an aspect of the present invention. 
55 Figure 24D shows the structure of a repository of interchanged objects which is us d in the steps shown 

in Figures 24A-24C. 

Figure 25 shows a computer network f rmed in accordance with the principles of th present invention. 
Figures 26A and 26B show a portion of the state of an agent process immediately prior to and following, 
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respectively, performance of peration "send". 

Figure 26C shows the state of a clone of the agent process immediately following p rformance of peration 
"send". 

Figures 27 A and 27B show the state of a engine process before and after, respectively, formation of clones 
of an agent process in performance of operation "send". 

Figure 28 shows the computer network of Figure 25 in which clones of the agent process have travelled 
to respective computer systems of the computer network in performance of operation "send". 

Figures 29A-29E show a computer network through which clones of an agent process travel according to 
another aspect of the present invention referred to as "deferred "cloning". 

Figure 30A shows the structure of a send frame including a nil and a list of tickets. 

Figure 30B shows the structure of an encoded clone of an agent process formed in accordance with an 
aspect of the present invention. 

Figures 31 A and 31 B show the state of a process immediately preceding and following, respectively, per- 
formance of operation "meet". 

Figure 32 is a logic flow diagram of the steps taken in performance of operation "meet". 

Figure 33 shows a portion of the state of an agent process including a set of contacts. 

Figures 34Aand 34B show the state of a process immediately preceding and following, respectively, per- 
formance of operation "meeting". 

Figure 35 is a logic flow diagram illustrating the steps taken in performance of operation "meeting" in ac- 
cordance with one embodiment of the present invention. 

Figure 36 shows the state of two agent processes which are interacting in accordance with an aspect of 
the present invention. 

Figures 37Aand 37B show a portion of the state of an agent process Immediately preceding and following, 
respectively, performance of operation "part". 

Figure 38 shows the state of the agent processes shown in Figure 36 immediately following performance 
of operation "part". 

Figures 39A-39F show a portion of the state of a first agent process during interaction with a second agent 
process in accordance with the present invention. 

Figure 40 is a logic flow diagram illustrating steps taken by the second agent process during the interaction 
shown in Figures 39A-39F according to one embodiment of the present invention. r 

Figure 41 Ashows the structure of a class definition in accordance with one aspect of the present invention. 

Figure 41 B shows the structure of a class object formed in accordance with one embodiment of the present 
invention. 

Figure 41 C shows the structure of a class object formed in accordance with a second embodiment of the 
present invention. 

Figure 42 shows the structure of an interface object formed in accordance with the present invention. 
Figure 43 shows the structure of a feature definition including a set, an identifier, and a boolean. 
Figure 44 shows the structure of an attribute definition including a constraint and a boolean. 
Figure 45 shows the structure of an operation definition including a constraint and a list, which in turn in- 
cludes a constraint 

Figure 46 shows the structure of a constraint 

Figure 47 shows the structure of an implementation object which includes two lists and six lexicons. 
Figure 48 shows the structure of a method which includes a procedure and a list, which in turn includes 
an identifier. 

Figure 49 shows the structure of the procedure of Figure 48. 

Figure 50 shows the structure of a citation which includes a telename, two integers, and an identifier. 
Figure 51 shows the structures of two cited objects, each of which includes a respective citation. 
Figure 52A is a logic flow diagram illustrating the steps taken in performance of operation "do". 
Figure 52B shows the structure of a predefined frame which includes an integer and a procedure. 
Figure 53 shows the execution state of a process which includes a stack, which in turn includes a user 
frame. 

Figure 54 shows the state of the user frame of Figure 53. 

Figures 55A and 55B combine as shown in Figure 55C to form a singl logic flow diagram illustrating the 
steps taken in performance of a user-defined operation. 

Figure 56A shows the execution state fa process which includes a stack, which in turn includes a frame. 

Figure 56B shows the execution state of the process f Figure 56A and a second frame. 

Figure 56C shows the x cut ion state of th process of Figures 56A and 56B, including th stack, which 
in turn includes th first-mentioned frame and the second frame. 
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Figure 57 is a logic flow diagram illustrating the steps taken in sel cting a feature definition and a method 
from the class hierarchy in accordance with the present invention. 

Figure 58A is a diagram showing th hierarchy of the classes of which a list is a memb r. 

Figure 58B is a diagram showing the hierarchy of the classes of which class "List" is a member. 
5 Figure 59 is a logic flow diagram illustrating the steps taken in the initialization of an object 

Figure 60 is a logic flow diagram illustrating the steps taken in performance of operation "if". 

Figure 61 is a logic flow diagram illustrating the steps taken in performance of operation "either". 

Figures 62A and 62B show a portion of the execution state of a process immediately preceding and fol- 
lowing, respectively, performance of operation "select". 
10 Figure 63 is a logic flow diagram illustrating the steps taken in performance of operation "select". 

Figure 64 shows the state of a predefined frame which represents the dynamic state of a performance of 
operation "select". 

Figure 65 is a logic flow diagram illustrating the steps taken in performance of operation "while". 

Figures 66A and 66B show a portion of the execution state of a process immediately prior to and imme- 
15 diately following, respectively, performance of operation "catch". 

Figure 67 is a logic flow diagram illustrating the steps taken in performance of operation "catch". 

Figure 68 is a logic flow diagram illustrating the steps taken in performance of operation "loop". 

Figure 69 shows the structure of a repeat frame which includes an executed object and two integers. 

Figure 70 is a logic flow diagram illustrating the steps taken in performance of operation "repeat". 
20 Figure 71 shows the execution state of a process which includes a stack which in turn contains, from top 

to bottom, a user-defined frame, a predefined frame, a repeat frame, and a second user-defined frame. 

GLOSSARY OF TERMS 

25 "Abstract Class": A class which is abstract has no instances. An abstract class can have subclasses, and an 
abstract class can define features, methods, and properties which are inherited by the subclasses of the ab- 
stract class. 

"Agent": An agent is a process which occupies a place and which is mobile, i.e. can move from a first place to 
a second place. 

30 "Arguments": An argument is an object "consumed" by performance of an operation as input data. In other 
words, an argument is an object transferred from the requester to the responder immediately prior to perfor- 
mance of the operation by the responder at the request of the requester. 

"Attribute": An attribute is a feature which either retrieves or sets information regarding the internal state of 

an object. Usually the information pertains to the object itself, but sometimes the information pertains to the 
35 reference by which the object is identified in invoking the attribute. An attribute is a pair of operations in which 

one sets, and the other retrieves, information regarding the internal state of the responder. 

"Authority": An authority is an entity which owns and controls various resources in the network. An example 

of an authority is a user of the network. Authorities are created administratively and cannot be created pro- 

grammatically, i.e., cannot be created at the request of a process. 
40 "Class": A class defines (i) zero or more properties, which define the internal states of the members of the class, 

(ii) zero or more methods, which define the internal behavior of the members of the class, and (iii) zero or more 

features, which define the external behavior of the members of the class. 

"Concrete Class": A class which is concrete can have instances. 

"Engine Place": Every engine contains exactly one engine place which represents the engine itself. 
45 "Engine": An engine is a machine in a computer system which manages objects, primarily processes, and exe- 
cutes instructions. An engine is typically a computer process executing within a computer system in addition 
to an operating system and various user applications. One or more engines can be executing within each com- 
puter system of a network. Each engine processes at least one place. 

"Exception": An exception is an object "thrown" by performance of a feature if the feature fails to be performed 
so completely and successfully. An exception, as the term is used herein, is alternatively a condition which causes 
such an object to be thrown. The responder is said to "throw" an exception, rather than "produce" an exception, 
because an exception arises from the failure of an operation and is therefore distinct from a result which is 
produced by a successful operation. The distinction betw en producing a result and throwing an exception is 
described in more detail below and in App ndix A which is hereby incorporated h rein in its entirety by refer- 
55 ence. 

"Feature": A feature is a task that an object can b directed to perform. The task is carried out by a method, 
which includes a set of computer instructions. Performance of a feature is accomplished by xecution f the 
computer instructions of th feature's method. A feature is associated with a specific class of objects, and per- 
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formance of a feature can vary with the specific internal state of the object performing the feature. Features 
are conceptually divided into the tw categories: (i) attributes and (ii) operations. 

"Fram ": A frame is an object which records th dynamic state of a method impl menting a feature during per- 
formance of the feature. A frame is used by an engine to maintain information regarding a method which the 
5 engine is executing, including information identifying the object performing the feature implemented by the 
method and the particular instruction that is currently executing. 

"Identifier": An identifier is an object which can reference a second object. The "text" of an identifier is a string 
which distinguishes the identifier from other identifiers within a particular scope. The various scopes of iden- 
tifiers are discussed in greater detail in Appendix A. 
10 "Implementation' 1 : An implementation is a set of computer steps performed in performance of a particular fea- 
ture. An "implementation object" is an object defining the various implementations of the various features of 
a class. 

"Instance": An object is an instance of a class if the object is a member of that class and is not a member of 
any subclass of that class. 

15 "Interface": An interface defines a particular attribute or the particular arguments consumed and the result pro- 
duced by performance of a particular operation. An "interface object" is an object defining the various interfaces 
of the various features of a class. 

"Member": An object is a member of the class of which the object is an instance and any superclasses of that 
class. 

20 "Method": A method is a set of computer instructions whose execution constitutes performance of a particular 
feature. A "method object" is an object defining a method. A method has a dynamic state during performance 
of the method, i.e., execution of the instructions of the method. The dynamic state of a method is represented 
by a frame. 

"Network": All engine places, the computer systems in which the engine places execute and communications 
25 apparatus connecting those computer systems collectively form a network. 

"Object": An object is an element in a computing environment within a computer system. An object has an in- 
ternal state defined by zero or more properties, an internal behavior defined by zero or more methods, and 
an external behavior defined by zero or more features. 

"Operation": An operation is a feature for which an interface and implementation is defined. 
30 "Place": A place is a process which is a locale for zero or more processes. A place can occupy a second place. 
The first-mentioned place is a sub pi ace of the second place, and the second place is a superplace of the first 
place. 

"Primitive": A primitive is an object that can be used in the formation of a procedure or a method, and that there- 
fore can serve as an instruction. 

35 "Process": A process is an object which constitutes an autonomous computation. A process is autonomous be- 
cause a process performs a method without being requested to do so by another object A process commences 
performance of a central method upon creation of the process, and the process is destroyed upon completion 
of the central method. Every object is owned by exactly one process. Every process is owned by itself. As 
used herein, the term "computer process" refers to a series of instructions carried out by a computer system, 

40 which is a more general and well-known definition. 

"Property": A property is an object which represents a part of the internal state of a second object 
"Reference": A reference is a data structure which identifies a particular object. An object, in being directed 
to perform a feature, is identified by a reference to the object supplied by the requester of the feature. Refer- 
ences are either protected or unprotected. An object cannot be altered or modified using a protected reference 

45 to identify the object 

"Region": A region is one or more engine places within a network which are controlled by a single authority. A 
region is generally distinguished by the close coordination and management of computer systems which sup- 
port the engine places of the region. The transportation of agents within a region is therefore generally quicker 
and less expensive than transportation of agents between regions. A region can be, for example, a local area 

so network which is connected to a wide area network. 

"Requester": A requester is an object which directs another object, i.e. the responder, to perform a feature. 
The r qu ster supplies zero or more objects as input data to the responder of th feature requested and re- 
ceives zero r one object as utput data from the responder of the feature. Dir cting an object to perform a 
feature is alternatively called "requesting" the object to perform th feature. 

55 "Responder": A responder is an object performing a feature at th direction of an ther object, i.e. the requester. 
The responder receives zero or more bjects as input data and supplies zero r on object as output data in 
performing the feature. A responder is alternatively called a "resp nding" object 

"Result": A result is an object "produced" by performance of an operation as output data. In other words, a result 
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is an object transferred from the respond er to the requester imm diately following performance f an operation 
by the responder at the request of the requester. 

"Subclass": A subclass inherits methods, properties, and/or feature definitions from one or more classes. A 
subclass can define one or more properties, methods, and/or features which are not inherited from any other 
5 class and can reimplement a feature which is inherited from another class by defining a new implementation 
of the feature. 

"Superclass": The classes from which a subclass inherits properties, methods, and/or features are superclass- 
es of the subclass. 

"Virtual Place": Every place which is not an engine place is a virtual place. 

10 

DETAILED DESCRIPTION OF A PREFERRED EMBODIMENT 

According to the principles of this invention, a novel set of computer processes are used to route a particular 
computer process to a selected computer system contained in a plurality of interconnected computer systems 

15 and to execute the particular computer process on the selected computer system. The computer processes of 
this invention are defined, in one embodiment, in terms of object-oriented computer processes. The computer 
processes of this invention include (i) an instruction set that defines the various operations in the process and 
(ii) an engine that interprets the instruction set and controls operation of a central processing unit (CPU) in 
performance of the computer processes. 

20 As explained more completely below, the particular computer process directs its own movement, i.e., 

transportation, through the computer network by executing an instruction which identifies a destination com- 
puter system within the network and directs that the particular computer process be transported there. While 
executing within the destination computer system, the particular computer process may have access to infor- 
mation which is not available elsewhere in the network. The particular computer process can access that in- 

25 formation and use that information to determine to which other computer systems to travel. As explained more 
completely below, the present invention provides computer processes with a level of mobility, extensibility and 
generality not found in the prior art 

In remote programming paradigms typically found in the prior art, a computer process does not direct its 
own movement, but is sent from a source computer system to execute within a destination computer system. 

30 If the computer process cannot direct its own movement throughout the network, the computer process cannot 
select further destination computer systems to which to travel on the basis of information obtained by the com- 
puter process at the destination computer system. Thus, such a computer process must return to the source 
computer system with the information obtained before being sent to a second destination computer system. 
As computer processes of the present invention can direct their own movement through the network, computer 

35 processes of the present invention represent a substantial extension of the traditional remote programming 
paradigm. 

Existing remote programming systems, which provide processes which direct their own movement through 
a computer network, lack generality and extensibility. Such systems lack generality in that such systems (i) 
are limited to homogeneous computer networks or (ii) require that a travelling process in a heterogeneous net- 
4Q work contain instructions which conform specifically to whichever computer system is executing the process, 
i.e. computer systems to which the travelling process travels. In the present invention, a process travels within 
a heterogeneous computer network and the execution of the instructions of the process is independent of which 
particular computer system within which the process executes, i.e., to which the process travels. As discussed 
below in greater detail, the computer instructions disclosed below are implemented uniformly by each of the 
45 computer systems of a heterogeneous network. Thus, a process formed in accordance with the present inven- 
tion can travel to any computer system within a heterogeneous computer network and execute there without 
any specific information regarding the nature of the computer system. 

Remote programming systems of the prior art typically lack extensibility in that a process cannot create a 
class of data objects and utilize data objects of that class within computer systems to which the process sub- 
so sequently travels. Many computer processes formed today are "object-oriented". As defined above in the Glos- 
sary of Terms, an object has (i) an internal state defined by a number of properties, (ii) an internal behavior 
defined by a number of methods, and (iii) an external behavir defined by a number of features. The prop rties, 
methods, andf aturesof agroup of obj cts with like prop rti s, methods, and features are defined by a class. 
In prior art systems, a process which defines a class cannot us objects of the class while executing in com- 
55 puter systems to which th process subsequently travels. Transportation of class definitions with travelling 
processes is not feasibl or practical in prior art systems becaus class definitions are not standardized; class 
definitions are generally very large and complex; and a single process generally uses objects of many classes. 
Class definitions are not "standardized" in that prior art systems are typically based n existing program- 
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ming languages which are not designed with mobile processes in mind. Therefore, class d finitions in a process 
form d using one of these existing programming languages typically rely on information specific to the com- 
puter system within which the process is created, such as the specific memory addresses of portions of the 
class definitions. Reliance on such information, which is specific to a particular computer system, makes class 

5 definitions of prior art systems very difficult to transport to remote computer systems. 

In the present invention, classes are represented by class objects which are part of the disclosed computer 
instruction set A process formed in accordance with the present invention includes class objects when trav- 
elling from one computer system to another. Thus, a process can define a class of object in a first computer 
system, travel to a second computer system, and utilize objects of the class within the second computer sys- 

10 tern. Unnecessary delay and expense in transporting all classes utilized by a travelling process are eliminated 
by transporting only those classes which are not defined within the computer system to which the process trav- 
els. 

Additionally, the present invention provides efficiencies not found in the prior art in transporting several 
clones of a process to several destination computer systems simultaneously. As discussed more completely 

15 below, substantial efficiencies are realized by deferring creation of one or more clones of the process so long 
as the travel path of one clone coincides with the travel path of another clone. Clones, and this aspect of the 
present invention, are discussed further below. 

In remote programming systems, two processes share information by a first process giving a second proc- 
ess access to the first process. The first process gives the second process access to the first process without 

20 simultaneously obtaining access to the second process. In such a situation, the second process is free to in- 
terfere with the execution of the first process without compromising the security of the second process. In the 
present invention, a first process obtains access to a second process and simultaneously gives to the second 
process access to the first process through the cooperation and coordination of a third process. Further se- 
curity is provided as the second process either accepts or rejects such an exchange with the first process ac- 

25 cording to the configuration of the second process. The third process ensures that (i) the second process 
agrees to such an exchange and that (ii) each process gains access to the other process simultaneously such * 
that neither process can interfere with the execution of the other process without affording a similar opportu nity 
to the other process. 

A novel computer process of this invention is an agent process. An agent process is a computer process 
30 formed of the computer instructions disclosed below in Appendix A, which is a part of this disclosure and which *' 
is incorporated herein by reference in its entirety. Agent processes are each interpreted by another novel com- 
puter process of this invention, i.e., an engine, and thereby effectuates the computer instructions disclosed 
below and in Appendix A. The term "interpreted" is used herein as it is understood in the art; a computer in- 
struction in a series of computer instructions is read and executed by an engine before the next computer in- 
35 struction in the series is read. 

Interpreting, rather than compiling, instructions of the disclosed instruction set provides greater generality. 
A first agent can travel from a first computer system to a second computer system and meet with a second 
agent there which gives to the first agent a procedure. The first agent can then perform the procedure which 
the first agent was not originally designed to perform. 
40 Yet another novel computer process of this invention is a place process. Place processes are dispersed 

throughout a computer network. Each agent process "occupies" a respective place process; i.e., a place proc- 
ess is part of the internal state of an agent process and therefore provides a context within which the agent 
process executes. Each agent process can initiate and control the agent process's transportation from a first 
place process to a second place process. "Agent" and "place" as used herein are shorthand terms for "agent 
45 process" and "place process", respectively. 

Figure 4A shows computer network 100 which includes computer systems 120A and 120B which are con- 
nected by communications link 102AB. Computer system 120Ais executing place 220Aand agent 1 50A. Agent 
1 50A occupies place 220Aas shown in Figure 4A. Computer system 120B is executing place 220B. Hereinafter, 
the statement that an agent or place occupies a particular place should be interpreted as including a statement 
so that the agent or place is executing within the computer system which contains the particular place. 

Agent 1 50A issues an instruction to computer system 120A. In response to the instruction, agent 1 50A is 
transported to a place, e.g. place 220B, specified in the instruction. The instruction is called peration "go", 
and the issuance of the instruction by agent 1 50A is call d herein performance of op ration "go" by agent 1 50A. 

Upon performance of operation "go" by agent 150A, (i) execution of agent 150A is suspended; (ii) agent 
55 150A is ncoded into a standardized f rm which preserves the execution state of agent 150A; (iii) the stan- 
dardized form of agent 1 50A is transported t computer system 1 20B; (iv) agent 1 50A, including the preserved 
ex cution stat , is d coded from the standardized form; and (v) execution of agent 150A is resumed within 
computer system 120B. After performanc of operation "go" by agent 150A, agent 150A no longer occupies 
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place 220Aand is no longer executing within computer system 120A; instead, agent 150A occupies place 220B 
and is executing within computer system 120B (Figur 4B). By enabling an agent to travel to a remote computer 
system in the midst of the agent's xecution, the agent is free t travel to data which the agent is configured 
to access. 

A standardized form is a form to which agents are encoded for the transportation of the agent from one 
computer system to another. The standardized form preserves the execution state of the encoded agent such 
that the agent can be decoded at the destination computer system and execution of the agent can resume by 
executing the instruction of the agent which sequentially follows operation "go*. Each computer system of the 
network of the present invention can maintain an agent in whateverform is convenient for carrying out the com- 
puter instructions included in the agent. However, in transporting an agent from one computer system to an- 
other, each computer system of the network must use the standardized form of an agent during transportation 
much the same way that two people must agree to the vocabulary and syntax of a single language to commu- 
nicate. The nature of the standardized form is discussed in greater detail in Appendices B, C and D t which are 
part of this disclosure, and in Appendices E and F which are incorporated in their entirety herein by reference. 

As an agent can direct its own movement, i.e., transportation, through the network, means must be pro- 
vided for specifying a number of parameters of a trip from a first computer system to a second computer sys- 
tem. A first parameter of a trip is the place to which the agent is transported, i.e., the destination of the trip. In 
one embodiment, a trip destination can be specified by name, by class, or by address. An address can be, for 
example, a location within a local area network. 

Frequently, two or more pathways exist between a first computer system and a second computer system. 
One pathway may be quick but expensive and another may be time consuming but inexpensive. In such a case, 
no single pathway is always preferred in the transportation of an agent. Therefore, a second parameter of a 
trip is the "way" and the "means" for travel of an agent 

In addition, errors in configuring an agent for a trip to a nearby computer system can cause the agent to 
be inadvertently transported to distant computer systems at considerable expense to the creator of the agent. 
Therefore, an important parameter of a trip is the amount of time or resources that can be expended in trans- 
porting the agent before the trip is aborted. 

Yet another important consideration in controlling the transportation of agents throughout a network is se- 
curity. For example, if all agents travelling to a particular computer system are granted ingress, the particular 
computer system may become overburdened with many processes requiring substantial processing, and 
throughput of the particular computer system can suffer. Therefore, another parameter of a trip is the amount 
of resources the agent requires at the destination place. Thus, the agent can be denied ingress to the place if 
the resources required by the agent are more than the place is able or willing to provide. 

In one embodiment, a ticket 1306 (Figure 4A) controls the transportation of agent 150Aand specifies place 
220B as the destination place. As shown in Figure 4A, agent 150A contains ticket 1306. Ticket 1306 defines 
the trip taken by agent 150Afrom place 220A to place 220B. In one embodiment, ticket 1306 specifies (i) the 
destination place of the trip, (ii) the Vay" or pathway and "means" agent 150A is to take to the destination 
place, (iii) the maximum amount of time within which the trip must be completed before the trip is aborted and 
(iv) the amount of resources agent 1 50A asks to use at the destination place. By specifying the amount of re- 
sources agent 150A is permitted to use at place 220B, place 220B can determine whether agent 150A requires 
more resources than place 220B is configured to provide. In such a situation, place 220B can deny ingress to 
agent 150A. Thus, using a ticket as described more completely below, an agent can completely define a pend- 
ing trip between a first place and a second place. 

As discussed above, the prior art process known to the inventors cannot manipulate objects of a class de- 
fined only in a previously occupied computer system. In other words, if a prior art process defines a class of 
objects and thereafter travels to a destination computer system, the process cannot manipulate objects of the 
class unless the destination computer system contains a definition of the identical class or the process defines 
the same class again within the destination computer system. As described in greater detail below, agents of 
the present invention, which travel from one place to another, transport definitions of classes which are not 
defined within the destination place. Thus, agents of the present invention can define a class within a first com- 
puter system, travel to a second computer system and manipulate objects of the class while executing within 
the second computer system. Agents of the present invention therefore represent a significant improvement 
over the known prior art processes. 

What is also generally lacking in the prior art is a means to implement a complex, multi-level security sys- 
tem in a computer network in which computer processes are m bile. On type of s curity which is afforded 
by the pres nt invention, and which is not suggested by the prior art, is th security afford d by places. As 
discussed in greater detail below, places, by granting or d nying ingress to various agents, provide various 
I vels of security and several places can b configured to provide multi-lev I, hierarchical security. 
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To assist in th understanding and visualization of the various aspects and embodiments of the pres nt 
invention, various representational and relational conventions are used in the drawings. Representational and 
relational conventions used herein are repres nted in Figures 5A, 5B and 5C. Computer system 120A (Figure 
5A) is executing place 220A, place 220X, place 220Y, agent 1 50A, agent 1 50X and agent 1 50Y. Computer sys- 

5 tern 1 20A also contains objects 140A, 140B and 140X in a memory, e.g., mass memory or main memory (nei- 
ther shown), of computer system 1 20A. Agent 1 50A and 1 50X occupy place 220A; place 220Y occupies place 
220X; and agent 150Y occupies place 220Y. Agent 150Aowns objects 140 A and 140B, and agent 150X owns 
object 140X The relationships of occupancy and ownership are discussed in greater detail below. Briefly, oc- 
cupancy of places provides various levels and types of security, and ownership determines which objects travel 

10 with an agent which performs operation "go". 

Figure 5B is an alternative and equivalent representation of the various relationships represented in, and 
described above with respect to, Figure 5A. While Figure 5A accurately represents, e.g., that agent 150X oc- 
cupies place 220A and contains object 140X, the form of Figure 5A is less suitable for representing more com- 
plex relationships. Therefore, the tree structure of Figure 5B is used in the drawings to represent more complex 

15 relationships in illustrating the various computer instructions of various embodiments of the present invention. 

The tree structure of Figure 5B should not be confused with the class hierarchy tree which is shown in 
part in Figure 5C. Figure 5C represents the class relationships of various items represented in Figures 5 A and 
5B. Objects 140A, 140B and 140X are members of class "Object" which is represented by class object 520. 
Membership in a class is discussed in greater detail in the Glossary of Terms above and is represented by a 

20 dashed line between the class and the object which is a member of the class. Class object 522 represents 
class "Process", which is a subclass of class "Object". Places 220X, 220Y and 220A are members of class 
"Place", which is a subclass of class "Process" and is represented by class object 524. Agents 150A, 150X 
and 150Y are members of class "Agent", which is a subclass of class "Process" and is represented by class 
object 526. Thus, places 220X, 220Y and 220A and agents 150A, 150X and 150Y are all members of class 

25 "Process" and are therefore computer processes. Objects 140 A, 140B and 140X are not members of class' 
"Process" and are therefore not computer processes. 

When an agent is transported from place to place, objects owned by the agent are transported with the 
agent from place to place. However, transporting an object can consume considerable resources if the object 
is large. In general, time in transporting an agent containing objects from a first place executing within a first 

30 computer system to a second place executing within a second computer system is substantially reduced by 
eliminating transportation of objects already at the second place. This is easily demonstrated by considering 
a simple example. Agent 150A (Figure 6A) is executing within computer system 120 A and occupies place 220A 
which is also executing within computer system 120 A. Agent 1 SOAowns objects 140A, 140B and 140C. In this 
embodiment, object 140B has digest 622. Digest 622 indicates that object 140B is interchangeable and that 

35 any object having a digest equal to digest 622 can be substituted for object 140B. 

Place 220B owns, and therefore contains, objects 624 and 626. Object 624 has digest 628. A process "con- 
tains" all the objects owned by the process and the classes of which the process and the objects owned by 
the process are members. 

In performance of operation "go", as indicated above, agent 150A and all objects contained by agent 150A 

40 are represented in a standardized form. However, object 140B is not included in the standardized form of agent 
150A. Instead, a copy of digest 622, i.e., digest 622-C (Figure 6B), is included in the standardized form of agent 
1 50A. Agent 150 A, objects 140 A and 140C, and digest 622-C are transported over communications link 1 02AB, 
in the direction of arrow A, to computer system 120B. Object 140B is held within computer system 120A at least 
until it is determined that an equivalent interchangeable object is found within computer system 120B. 

45 At computer system 120B (Figure 6C), agent 150A, objects 140 A and 140C, and digest 622-C are decoded. 

In decoding agent 150A, computer system 120B recognizes digest 622-C and determines whether an object 
with an equivalent digest occupies place 220B. Object 624 occupying place 220B has digest 628 which is equal 
to digest 622, and is therefore equal to digest 622-C. Since digest 628 is equal to digest 622, objects 140B 
and 624 are interchangeable. Therefore, in decoding agent 150A, a copy, e.g., object 624-C, is made of object 

so 624 and substituted within agent 150A for interchangeable object 140B. Agent 150A therefore owns object 624- 
C, which is a copy of object 624, in lieu of object 140B. Thus, transportation of object 140B to place 220B is 
obviated. Since an equivalent interchangeable object is found within computer system 120B, obj ct 140B can 
be d leted from computer system 120 A- Of course, th re are situations in which an equivalent interchanged 
object is not found on computer system 120B. In such a situation, object 140B (Figure 6B) is retrieved from 

55 computer 120A as described more completely b low. 

An agent, occupying a first place, is capable of creating one or more clone processes of the agent and 
transporting each don process to a resp ctive place. Thus, in effect, an agent is capabl of traveling to and 
occupying several places simultaneously. Of course, it is not a single agent that travels simultaneously but 
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rather th clones of the agent 

To travel to and occupy several places simultaneously, an agent issues an instruction which creates mul- 
tiple clon s of the agent and causes each clone to travel to a respective place. Each clone is an agent, and, 
at the time of a clones creation, the done is identical to the original agent, and therefore includes an execution 
5 state identical to that of the original agent 

For example, agent 150A, which occupies place 220A in computer 120A (Figure 7A), issues an instruction 
to computer system 120A which creates clones of agent 150Aand transports the clones to occupy one or more 
places, e.g., place 220B in computer system 120B and place 220C in computer system 120C, which are spe- 
cified in the instruction issued. The instruction is called operation "send", and the issuance of the instruction 
10 by agent 150A is called herein performance of operation "send" by agent 150A. Performance of operati n 
"send" by agent 150Aas represented in Figures 7A, 7B, 7C and 7D is controlled, in this embodiment, by two 
tickets (not shown) within agent 150A. The two tickets control the transportation of respective clones and spec- 
ify places 220B and 220C as the places to which respective clones of agent 150A are to be transported. 
Agents 150A-1 and 150A-2 (Figure 7B) are clones formed from agent 150A, and are identical to agent 
15 1 50A except that agents 150A-1 and 150A-2 do not occupy place 220A. As described above, even the exe- 
cution states of agents 1 50A-1 and 1 50A-2 are initially identical to the execution state of agent 1 50A. Agents 
1 50A-1 and 1 50Ar2 travel along intercomputer communications link 1 20ABC (Figure 7C), as described in great- 
er detail below, to respective places 220B and 220C. 

After performance of operation "send" by agent 150A (Figure 7D), agent 150A continues to occupy place 
20 220A. Agent 150A-1 occupies place 220B, and agent 150A-2 occupies place 220C. 

Space in computer system 120Aand time in transporting clones of agent 150A are saved by deferring com- 
plete cloning of an agent 150 A so long as the travel path of one clone coincides with the travel path of another 
clone, i.e., at least two clones have some Initial portion of their Journey that is coextensive. For example, In 
Figure 7E, both clones of agent 150 A must pass through computer system 120D to reach respective destination 
25 places 220B and 220C. Therefore, only a single clone of agent 1 50A, namely, agent 1 50A-1 , is transported to 
computer system 120D. A second clone of agent 150A, namely, agent 150A-2, is formed in computer system 
120D from agent 150A-1. Agents 150A-1 and 150A-2 are then transported to respective destination places 
220B and 220C. Thus, only a single clone of agent 150A is formed in computer system 120Aand only a singl 
clone is transported to computer system 120D saving space in computer system 120Aand time in transporting 
30 agents 150A-1 and 1 50A-2 to their respective destinations. 

Two agents exchange information by participating in a meeting between the two agents. In such a meeting, 
each agent is provided with a reference to the other agent. As discussed below, a first agent, which possesses 
a reference to a second agent, (i) can direct the second agent to take specific actions in accordance with in- 
structions contained with the second agent and (ii) can transferdata to and receive data from the second agent. 
35 In one aspect of the present invention, an agent is prevented from interfering with other agents by requiring 
that no agent be given a reference to a second agent unless the second agent is given a reference to the first- 
mentioned agent. In that way, no agent can gain access to a second agent without granting reciprocal access. 

A first agent, occupying a place, can initiate a meeting with a second agent occupying that place. During 
such a meeting, the first agent can transfer objects to and receive objects from the second agent, and th 
40 second agent can transfer objects to and receive objects from the first agent 

A subclass of class "Place" (Figure 5C) is class "Meeting Place" (not shown). In the illustrative example 
of Figures 8A-8F, place 220B is a member of class "Meeting Place" and is therefore a meeting place. Therefore, 
place 220B is sometimes referred to herein as "meeting place 220B". Meeting place 220B (Figure BA), which 
is executing in computer system 120B. provides a means for agents 150Aand 150B, which occupy meeting 
45 place 220B, to communicate and share information in a meeting as indicated by arrows A and B. Petition 3106 
within agent 150A defines and controls the meeting between agents 150 A and 150B. 

A meeting between agent 1 50A and 1 SOB is arranged as illustrated by Figures 8B-8F. Agent 1 50A (Figure 
8B) issues a first computer instruction, represented by arrow 851, directing meeting place 220B to arrange a 
meeting between agents 150Aand 150B. The first instruction includes petition 3106, which controls the meet- 
so ing, and which specifies that agent 150A wants to meet with agent 1 SOB. On behalf of meeting place 220B 
(Figure 8C), the engine issues a second computer instruction, represented by arrow 852, which notifies agent 
150B that agent 150A has issued the first computer instruction, and which causes execution of a number of 
computer instructions within agent 150B to determine wh ther a me ting b tween agents 150Aand 150B is 
acceptabl . 

55 Upon d termination that the m eting betw en agents 150Aand 150B is acceptable (Figure 8D), agent 

150B issues a reply, repres nted by arrow 853, to the second computer instruction, directing the engine, n 
b half of me ting place 220B, to proceed in arranging the meeting between agents 1 5QA and 1 SOB. On behalf 
f meeting place 220B (Figure 8E), the engin conv ys to agent 1 50A a reference to agent 1 SOB, the convey- 
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ance b ing represented by arrow 854A, and conveys to agent 1 50 B a reference to agent 1 50A f the conveyance 
being represented by arrow 854B. Agent 150A (Figure 8F) interacts with agent 150B using the referenc to 
agent 150B, th reference being represented by arrow 855A, and agent 150B interacts with agent 150A using 
the reference to agent 150A, the reference being represented by arrow 855B. 

5 Two agents cannot participate in a meeting together unless the two agents occupy the same place. A hi- 

erarchy of places provides users of the present invention a mechanism to provide varying levels and types of 
access and security to various agents. The benefit of various levels and types of access and security is dem- 
onstrated by the illustrative example of Figures 9A-9E. 

Figure 9Ashows a building 902 having floors 902-1 , 902-2, 902-3, 902-4 and 902-5. Floor 902-3 is a place 

10 within the place of building 902 and is therefore a subplace of building 902. Figure 9B shows floor 902-3 having 
rooms 902-3-1, 902-3-2, 902-3-3, and 902-3-4. Room 902-3-2 is a place within the place of floor 902-3 and 
is therefore a subplace of floor 902-3. 

The organization of building 902 lends itself to hierarchical security. For example, building 902 can be re- 
stricted to allow only people of a first level of security, e.g., military personnel, to enter. Floor 902-3 can be 

15 further restricted to allow only people of a second (higher) level of security, e.g., naval personnel, to enter. 
Room 902-3-2 can be still further restricted to allow only people of a third (still higher) level of security, e.g., 
naval officers, to enter. Floor 902-4 can be restricted independently of floor 902-3, e.g., to allow only air force 
personnel to enter. 

The engine in computer system 120X (Figure 9C) is executing places 220X1 and 220X2. Place 220X1 can 

20 represent, for example, building 902. Places 220X1-1 and 220X1-2, which represent, for example, floors 902- 
4 and 902-3, occupy place 220X1 (Figure 9D) and are therefore subplaces of place 220X1. Conversely, place 
220X1 is a superplace of places 220X1-1 and 220X1-2. Race 220X1-2-1 , which represents, for example, room 
902-3-1 , occupies place 220X1 -2 (Figure 9E). Place 220X1 -2-1 is therefore a subplace of place 220X1-2, and 
place 220X1-2 is a superplace of place 220X1-2-1 . 

25 In one embodiment of the present invention, two agents can only meet "face-to-fece", i.e., when both 

agents occupy the same place. As used herein, an agent "occupies" one place only and does not simultane- 
ously occupy subplaces or superplaces of the place. For example, an agent occupying place 220X1-2 does 
not simultaneously occupy place 220X1 or place 220X1-2-1. Just as a first person in building 902 (Figure 9A) 
cannot communicate face-to-face with a second person on floor 902-3 unless the first person is also on floor 

30 902-3, an agent occupying place 220X1 (Figure 9D) cannot communicate with an agent occupying place 
220X1-2. As a first person on floor 902-3 (Figure 9B) cannot communicate face-to-face with a second person 
in room 902-3-2 unless the first person is also in room 902-3-2, an agent occupying place 220X1-2 (Figure 
9E) cannot communicate with an agent occupying place 220X1-2-1 . 

Such a place hierarchy enables a user of the present invention to restrict access to place 220X1 , to further 

35 restrict access to place 220X1 -2 and to restrict access to place 220X1 -2-1 further still. Additionally, the security 
hierarchy implemented is not necessarily directly related to the place hierarchy implemented. For example, 
access to place 220X1-2 can be more restrictive than access to a subplace of place 220X1-2, such as place 
220X1-2-1. The restriction of access to a place is described in greater detail below. Thus, the place hierarchy 
enables a user of the present invention to construct sophisticated security hierarchies in which various agents 

40 are given various levels of access to other agents which occupy certain places, subplaces of those places, 
and subplaces of those subplaces. 

To describe further details of the novel processes described above, a better understanding of the structure 
of the computer systems described above is required. In the embodiment shown in Figure 10, three computer 
systems are connected to form a computer network 1 00. Computer system 1 20A includes CPU 1 1 0A, network 

45 communications hardware 104 A, and memory 117A. Input and output modules corresponding to input modul 
1 2 and output module 14 of Figure 1 are omitted for clarity. Additionally, mass memory 1 7A and main memory 
1 7B of Figure 1 are combined to form memory 11 7A. Network communications hardware 104 A can be any de- 
vice which enables CPU 11 OA to propagate signals across and to receive and interpret signals from the net- 
work. 

so Within memory 11 7A are a number of computer processes operating concurrently within CPU 11 OA. Net- 

work manager 130A is a computer process which coordinates data transmission between the various computer 
systems of the computer network. Operating system 1 31 A is a computer process which coordinates the oper- 
ation f the various components and resources of computer system 120A. For exam pi , operating system 131 A 
coordinates th us of components CPU 11 OA, mem ry 11 7A and I/O modules (not shown in Figure 10, see 

55 Figure 1 ). Engin 1 32A is a computer process which interprets computer instructions of an object-oriented com- 
puter instruction set of this invention and processes information in th form of objects defined in that object- 
oriented computer instruction set For example, engin 132A effectuates concurrent execution of place 220A 
(Figure 4A) and agent 150A, both of which are process s constructed of the object-oriented computer instruc- 
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tion set of the pres nt invention. Engine 132A is not shown in Figure 4A. 

In addition to these processes operating within memory 117A(Figure 10) of computer system 120A, there 
are typically one r more processes which are user applications, e.g. user applicati n 133A. User application 
1 33A can request of engine 132A the creation of and/or manipulation of objects defined within the object-ori- 

5 ented instruction set interpreted by engine 132A. 

Computer systems 120B and 120C are configured similarly to computer system 120A. However, while the 
general structure of computer systems 120A, 120B and 120C are similar, computer systems 120A, 120B and 
120C can be otherwise heterogeneous. 

The computer systems of computer network 100 are connected such that an agent process can be trans- 

10 ported from one computer system to another. Computer systems 120A, 120B and 120C are connected to form 
a computer network by coupling the respective network communications hardware 104A, 104B and 104C by 
means of communications links 102AB, 102BCand 102AC. Communications links 102AB, 102BCand 102AC 
can be any means by which data can be conveyed from one network communications hardware, e.g., network 
communications hardware 104Ato another, e.g. f network communications hardware 104B. For example, net- 

15 work communications link 102AB can be the public switched telephone network, in which case network com- 
munications hardware 104 A and 104B are modems and network managers 130 A and 130B are capable of is- 
suing commands to network communications hardware 104A and 104B, respectively, to establish and utilize 
communications via communications link 102AB i.e., the public switched telephone network. 

Objects constructed of the object-oriented computer instruction set are executed by an engine, e.g., en- 

20 gine 132A (Figure 11A). Engine 132A has a communication infrastructure 132A-CI, a program portion 132A- 
P, and a data portion 132A-D. Data representing the state of the various objects executed by engine 132A, 
e.g., object 140A, are stored in data portion 132A-D of engine 132A. Data portion 132A-D of engine 132A is 
memory space within memory 117A (Figure 10) reserved as work space for engine 132A and is generally in- 
accessible from the perspective of other processes on computer system 120A, e.g. operating system 131A 

25 and user application 1 33A. 

As discussed above, an engine effectuates execution of processes and objects. Program portion 1 32A- 
P (Figure 11 A) of engine 132A includes computer instructions which effectuate execution of the objects rep- 
resented in data portion 1 32A-D. The computer instructions which are combined to form program portion 1 32A- 
P can be of a known computer language. For example, the computer software in Appendix G is a program por- 

30 tion of an engine constructed in accordance with the principles of the present invention and is constructed in 
accordance with the C++ programming language. 

Communication infrastructure 132A-CI of engine 132A includes computer instructions which transport 
data between engines dispersed throughout network 100. Many aspects of the communication infrastructure 
of an engine are described in greater detail in Appendix D, which is a part of this disclosure. 

35 Figure 11B is an alternative and equivalent representation of the computer network of Figure 11 A. 

As indicated by Figure 11 A, engine 132B of computer system 120B is configured in a manner that is directly 
analogous to the configuration of engine 132A. 

Objects within the Network 

40 

As explained more completely below, places 220A and 220B (Figure 4A), agent 150A, ticket 1306, etc. 
are defined using "objects" according to the principles of this invention. As stated above, objects, which are 
formed according to the computer instruction set interpreted by engines 132A and 132B and which are inter- 
preted by engine 1 32A, are stored in data portion 1 32A-D (Figure 1 1 A). For example, object 1 40A in data portion 
45 132A-D is formed according to the computer instruction set interpreted by engines 132A and 132B and is in- 
terpreted by engine 132A. 

Brief Overview of the Computer Instruction Set of the Present Invention 

so Each of the novel processes of this invention, and the features needed to define and support the proc- 

esses, are defined by a set of computer instructions that are interpreted by an engine of this invention. Th 
computer instructions of the present inv ntion are object-oriented. Therefore, data in the present inv ntion, 
e.g., data which represent agent 150A, are organized into objects, each of which has an internal state and an 
external behavior. An object's properties define the object's internal state and th objecf s features def in the 

55 object's xternal behavior (see Glossary of Terms above). Each object is an instance of a resp ctive one of a 
number of classes. 

According to th principles of this inv ntion, all classes defined in the computer instruction set, except for 
mix-in classes which are described below, are subclass s of a class "Object", which is described more com- 

20 
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pletely in Appendix A. Thus, each class that is described herein and which is not a mix-in class inherits the 
features and properties of class "Object*. 

In ne embodiment, limited multiple inheritance is implemented using mix-in classes. "Mix-ins" or "mix-in 
classes" are classes which are not subclasses of class "Object". Examples of mix-in classes, which are de- 
scribed below and in Appendix A, include mix-in classes "Executed", "Named" and "Referenced". A non-mix- 
in class, alternatively called a "flavor" or a "flavor class", can be the immediate subclass of at most one flavor, 
but can be the immediate subclass of zero or more mix-in classes. A mix-in class can be the immediate subclass 
of no class or of another mix-in class. Unless otherwise stated, a class is a flavor. No cycles in class hierarchy 
are permitted; i.e., no class is permitted to be both a subclass and a superclass of another class. 

The use of mix-in classes allows features and properties to be defined once and used across a broad va- 
riety of classes. For example, mix-in class "Ordered" defines operations for determining the relative order of 
two objects. Flavor classes "Association", "Citation", "List", "Identifier", "Pattern", "Permit", "Bit", "Boolean", 
"Character", "Number", "Octet" and T\me" inherit from mix-in class "Ordered". Thus, associations, citations, 
lists, identifiers, patterns, permits, bits, booleans, characters, numbers, octets and times have an order rel- 
ative to other members of the same class. For example, in the case of numbers, the number two is "after" the 
number one and is "before" the number three. 

The principal class of objects in the present invention is the class of processes. As described above, proc- 
esses are either (i) places which are occupied by other processes, or (ii) agents which can (a) transport them- 
selves from a first place, terminating occupancy of the first place, to occupy a second place and (b) interact 
with other agents occupying the same place. 

Agent 150A (Figure 11 A) is a process formed in accordance with the computer instruction set of the present 
invention whose execution is carried out by engine 132A. Agent 150Acan (f) examine and modify itself, (ii) 
transport itself from a first place in network 1 00 (Figure 1 0) to a second place, and (III) interact with other agents 
which occupy the second place. 

Herein, a process is described as performing an operation that consumes arguments and produces zero 
or one result. However, a process, in and of itself, is an object that includes a collection of instructions, which 
are selected from the instructions described more completely below, and which is interpreted by an engine, 
e.g., engine 132A which is executing in CPU 110A. The performance of an operation by a process, or any other 
object of the disclosed instruction set, is in actuality the selection of and interpreting of a particular group of 
the instructions included in the process or object Interpreting the instructions of a process by an engine is 
herein alternatively called "interpreting the process". Thus, when agent 150A performs an operation, agent 
150A provides instructions to engine 132A which in turn interprets the instructions and directs CPU 110Ato 
carry out appropriate tasks effectuating performance of the operation by agent 1 50A. The interaction between 
a process and an engine is described more completely below. 

An important aspect of the present invention is that the set of computer instructions described more com- 
pletely below is implemented uniformly by the respective computer systems of network 100 (Figure 10). Com- 
puter systems 120A, 1 20B and 120C can use completely different and incompatible data structures, memory 
configurations, CPUs and operating systems. But, since an agent is capable of transporting itself to and from 
any of computer systems 120A, 120B and 120C, it is important that each computer system implement the set 
of computer instructions of the present invention in a standardized fashion. As long as the computer instruc- 
tions are uniformly implemented, computer systems 120A, 120B and 120C can be otherwise incompatible. 
Therefore, agents can travel freely among the computer systems of a heterogeneous, as well as a homoge- 
neous, computer network. 

Typically, prior art systems either required that processes travel only within homogeneous networks or that 
processes be specifically designed to execute computer instructions which were compatible with the computer 
system within which the process was executing. In the latter case, processes were configured for the particular 
system requirements of the computer system on which execution of the process began and for the particular 
system requirements of any computer systems to which the process was intended to travel. Thus, as the com- 
puter instructions of an agent of the present invention can execute on any computer system of a heterogeneous 
network, the present invention represents a substantial improvement over the prior art. 

Agents 

As discussed above, the behavior of an agent is dependent in part on the internal state of the agent There- 
f re, prior to considering the external behavior of an ag nt in a network, several aspects of the internal state 
f an agent are briefly discussed. Each agent is a member of class "Agent". 

It should be noted that no agents are instances f class "Agent," as class "Agent" is abstract Class "Agent" 
is abstract as no implementation for operation "liv "isd fined or inherited by class "Agent". As discuss dbelow 
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and in Appendix A in greater detail, operation "liv ° defines the steps that are performed by a process, i.e., an 
agent or a place, upon creation of the process. These steps are collectiv ly called the "central procedure" of 
the process. A central proc dure for either agents or places is not provided as us rs of the present invention 
design and provide central procedures for agents and places to suit the particular needs of each user. Thus, 
s users of the present invention create concrete subclasses of class "Agent" and therein provide implementations 
for operation "live". 

Class "Agent" is a subclass of class "Process". (See Figure 5.) Class "Process" is a subclass of class "Ob- 
ject" and also inherits from mix-in class "Named". Class "Object" inherits from mix-in class "Referenced". An 
agent possesses the following attributes: (i) attributes "class" and "size" inherited from superclass "Object"; 
10 (ii) attribute "isProtected" inherited from mix-in class "Referenced"; (iii) attribute "name" inherited from mix-in 
class "Named"; and (iv) attributes "brand", "permit" and "privateClasses" inherited from superclass "Process". 
Class "Agent" defines no attributes. Each of the above-mentioned attributes and classes is discussed in more 
detail in Appendix A. 

Diagram 1270 (Figure 12) illustrates the class relations of the classes of which agent 150Ais a member. 
15 Agent 1 50A is a member of class "Agent" as agent 150A is shown to be contained within domain 1272 which 
represents class "Agent". Since class "Agent" is abstract, agent 150A is also a member of one or more sub- 
classes (not shown) of class "Agent". 

Domain 1272 is completely contained within domain 1274 which represents class "Process". Agent 150A 
therefore inherits attributes "brand", "permit" and "privateClasses", which are defined by class "Process". Ad- 
20 ditionally, all members of class "Agent" are also members of class "Process". Thus, as described above, class 
"Agent" is a subclass of class "Process". 

Domain 1274 is completely contained within domain 1276 which represents class "Object". Agent 150A 
therefore inherits attributes "class" and "size" which are defined by class "Object". Additionally, all members 
of class "Process", including members of class "Agent", are also members of class "Object". Thus, as described 
25 above, class "Process" is a subclass of class "Object". 

Domain 1274 representing class "Process" is contained within domain 1278, which represents class 
"Named". Connection 1278A shows that domain 1274 is contained within domain 1278 while accurately rep- 
resenting that domain 1276, representing class "Object", is not contained within domain 1 278 and that domain 
1278 is not contained within domain 1276. Class "Named", represented by domain 1278, is a mix-in class. As 
30 domain 1274 is contained within domain 1278, agent 150A is contained within domain 1278 and is therefore 
a member of mix-in class "Named". Mix-in class "Named" defines attribute "name" which is included in agent 
160A. 

Domain 1280 which represents mix-in class "Referenced" contains domain 1276, which represents class 
"Object", as indicated by connection 1280A. As domain 1276 is contained within domain 1280, agent 150A is 
35 contained within domain 1280 and is therefore a member of mix-in class "Referenced". Mix-in class "Refer- 
enced" defines attribute "isProtected" which is included in agent 150A. 

As every flavor of the disclosed embodiment of the present invention is a subclass of class "Object", every 
flavor is also a subclass of mix-in class "Referenced". Thus, it is not necessary to separate the features of class 
"Referenced" from the features of class "Object". However, the features of mix-in class "Referenced" are sepa- 
40 rated from the features of class "Object" to aid conceptualization and understanding of the present invention. 

As discussed above in the Glossary of Terms, objects are identified within the disclosed computer instruc- 
tion set by references. As discussed in greater detail below, in directing an object to perform an operation, the 
object is identified by a reference. Features defined by mix-in class "Referenced" operate on the reference 
which identifies the object Forexample, attribute "isProtected"determines whether the reference to the object, 
and not the object itself, is protected. Features defined by class "Object" operate on the object identified by 
the reference. For example, attribute "class" determines of which class the object is an instance. 

It should be noted that no attribute is defined which provides information regarding the place occupied by 
agent 1 50A (Figure 1 2). However, the place occupied by agent 1 50A is maintained as a property of agent 1 50A. 
Agent 1 50A can determine which place agent 1 50A occupies by execution of the "here" selector. The execution 
of selectors, and in particular the "here" selector, is discussed in greater detail in Appendix A. The property 
which is the place occupied by agent 150A is defined by class "Process". Thus, any process, i.e., either a place 
or an agent, includes a property which is the place occupied by the process. 

While th only class disclosed herein and in Appendix A which is an immediate subclass of mix-in class 
"Named" is class "Process", subclasses of mix-in class "Named", which are not subclasses of class "Process", 
are defined by users of th present invention using the instructions disclosed herein and in Appendix A. There^ 
fore, class "Named" is a mix-in class. 
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Agents as Processes 

Associated with very process, both agents and places, is a central procedure which defines the primary 
behavior of the process as discussed above. The central procedure of a process is the method which imple- 
ments an operation "live" as performed by the process. An engine initiates processing of a process by causing 
the process to perform operation "live", thereby causing execution of the process's central procedure. The pro- 
vision of a method for an operation is discussed in greater detail below. When a process completes perfor- 
mance of operation live", either successfully or otherwise, the process is terminated. The termination of a proc- 
ess is discussed in section 2.4.11 of Appendix A and that discussion is incorporated herein by reference. 

Mobility of Agents: Operation "Go" 

As discussed above, an agent travels from one place to another by performance of operation "go". Oper- 
ation "go" is discussed in the context of the illustrative example of Figures 15A-1 5E. To travel from place 220A 
to place 220B, agent 150A (Figure 15A) performs operation "go". Figure 15A shows the state of network 1500 
prior to performance of operation "go" by agent 150 A 

Agent 150 A owns objects 140Aand 140B and occupies place 220A in engine 1 32A. Thus, agent 150Aand 
place 220A are processes which are simultaneously interpreted by engine 132A. In other words, place 220A 
and agent 150A are simultaneously performing operation "live". Engine 132B interprets place 220B and agent 
150B. Agent 150B occupies place 220B. 

Communication infrastructure 132A-C1 of engine 132A is connected to communication Infrastructure 
132Z-CI of engine 132Z by communications link 102AZ. Engine 132Z interprets place 220Z. Communication 
infrastructure 1 32Z-CI is also connected to communication infrastructure 132B-CI of engine 132B by commu- 
nications link 102ZB. While in this embodiment only three computer systems are illustrated in network 1500, 
the number of computer systems in network 1500 is an arbitrary number, Hence, the computer systems illu- 
strated in Figure 15Aare illustrative of the principles of the invention and are not intended to limit the invention 
to the particular network illustrated. 

Performance of operation "go" by agent 150A, in this embodiment, requires transportation of agent 150A 
from engine 132A through engine 132Z to engine 132B. Hence, operation "go" requires action on the part of 
engine 132A, i.e., the source engine, engine 1322, i.e. the transit engine, and engine 132B, i.e., the destination 
engine. 

Operation "Go" as Performed by the Engine Processing the Source Place 

Figure 13A shows a portion of the internal state, including a portion of the execution state, of agent 150A 
immediately prior to performance of operation "go" by agent 150A. The execution state of a process is descri- 
bed in greater detail below. Stack 1304 is a part of the execution state of agent 150A Stack 1304 contains, at 
top T, ticket 1306. Ticket 1306 is described more completely below. Arguments consumed by performance 
of operation "go" are popped from stack 1 304 and stack 1304 is therefore the "current stack" in the context of 
operation "go". Place 220A is a property of agent 150 A indicating that agent 150A occupies place 220A 

Figure 13B shows a portion of the internal state, including a portion of the execution state, of agent 150A 
immediately following performance of operation "go" by agent 150 A Figure 13B is described in greater detail 
below. 

Logic flow diagram 1400 (Figure 14A) illustrates operation "go" as carried out by engine 132A (Figure 15A). 
Engine 132A is the source engine as agent 150A is executing within engine 132A when performance of oper- 
ation "go" is initiated. The steps of logic flow diagram 1400 (Figure 14A) are discussed in the context of th 
trip from place 220A (Figure 15A) to place 220B taken by agent 150 A 

In performance of operation "go" by agent 1 50A, engine 1 32A (Figure 1 5A) determines whether agent 150A 
is the agent requesting performance of operation "go" in an access test step 1402 (Figure 14A). If operation 
"go" is requested by an object other than agent 1 50A (Figure 1 5A), processing transfers from access test step 
1 402 (Figure 14A) to terminal step 1404 in which an exception of class "Process Not Current" is thrown causing 
op ration "go" to fail. If, how ver, operation "go" is requested by agent 150A (Figure 15A), processing transfers 
from access test step 1402 (Figure 14A) to a "canGo" test step 1406. 

In "canGo" test st p 1406, engine 1 32A (Figure 1 5A) determines whether agent 1 50A is permitted to per- 
form peration "g ". In "canGo" test step 1406, engine 132A (Figure 15A), queries attribute "permit" of agent 
1 50A. Attribute "permit" as discussed above, is ne of a plurality of attributes of agent 1 50A The various at- 
tributes of agent 1 50A are described in greater detail in Appendix A in conjunction with class "Process". Th 
qu ry f attribute "permit" of agent 1 50A produces property "permit" of agent 1 50A. Specifically, permit 1 612 
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(Figure 16) is property "permit" of agent 150Aand is th refore produced by querying attribut "permit" of agent 
1 50A. In this emb diment, property "permit" is one of a number of properti s of agent 1 50A. 

P rmit 1612 (Figure 17) includes, among several properties which are described in greater detail in Ap- 
p ndix A, properties "charges". "canGo", and "age" which are integer 1702, boolean 1704, and integer 1706, 
5 respectively. A boolean is an object having one of only two possible values: "true" or "false". In "canGo" test 
step 1406 (Figure 14A), engine 132A(Figure 15A) queries attribute "canGo" of permit 1612 (Figure 17), thereby 
producing boolean 1704 which is property "canGo" of permit 1612, and compares boolean 1704 to "true". 

If boolean 1704 has a value of "false", processing transfers from "canGo" test step 1406 (Figure 14A) to 
terminal step 1408. Agent 150Ais not permitted to travel by performance of operation "go" and the operation 
10 fails and throws an exception that is a member of class "Permit Violated" in terminal step 1408. Exceptions 
and their classification are described more completely in Appendix A. 

Otherwise, if boolean 1704 (Figure 17) has a value of "true", processing transfers from "canGo" test step 
1406 (Figure 14A) to an effectuate move step 1410. Effectuate move step 1410 is described in greater detail 
below in conjunction with Figure 14B. Processing transfers from effectuate move step 1410 (Figure 14A) to 
15 terminal step 1412 in which operation "go", to the extent engine 132A is involved, completes successfully. 

Effectuate move step 1410, which is performed by engine 132A (Figure 15A) as described above is rep- 
resented by logic flow diagram 1410 (Figure 14B). In the first step of logic flow diagram 1410, i.e., route agent 
step 1414, engine 132A(Figure 15A) selects an engine to use in transporting agent 150Ato the trip destination, 
i.e., a "transfer destination". As used herein, the transfer destination is the next engine used in the trip and 
20 should not be confused with the "trip destination". Ticket 1306 (Figure 13A) defines a place as the destination 
of a trip; therefore, the "trip destination" is a place. In the course of the trip defined by ticket 1306 (Figure 13A), 
agent 150A (Figure 15A) is transferred from one engine to another. Therefore, a "transfer destination" is an 
engine. In general, a trip can require several transfers of an agent before the agent reaches an engine which 
contains a trip destination. 

25 in step 1414 (Figure 14B), a way object, i.e., a member of class "Way", which defines a transfer destination 

is produced. The transfer destination can be, for example, (i) the engine which currently contains agent 1 50A 
i.e., engine 1 32A, in which case agent 1 50A is not transferred, (ii) another engine in the region which contains 
engine 1 32A, or (iii) an engine in another region. In either of possibilities (ii) or (Hi), agent 1 50A is transferred 
to the transfer destination as described below. 

30 The term "region" is defined above in the Glossary of Terms. The grouping of engines into regions is sig- 

nif icant in the routing of an agent as each engine typically contains more detailed information regarding other 
engines within the same region than engines of other regions. This is true because engines of a single region 
are configured by a single person or organization, which is therefore called the "provider" of the region. There- 
fore, each engine of a region can be given detailed information regarding other engines of the region as all 

35 such engines are provided by a single provider. 

The grouping of engines into regions is helpful in routing agents in large and complex networks. When an 
agent travels between regions, it is not imperative that the source engine contain any information regarding 
the transfer destination engine. It is sufficient that the source engine can determine to which region the agent 
is traveling and can transfer the agent to an engine in that region. Once transferred to an engine in the region 

40 containing the place that is the trip destination, the agent can be more easily routed to an engine containinq 
that place. a 

Logic flow diagram 1414 (Figure 14C) shows the steps carried out in route agent step 1414 (Figure 14B) 
and is discussed below in greater detail. 

Processing transfers from route agent step 1414 to an isolate agent step 1416 where agent 150A (Figure 
1 5A) is isolated. Isolation of a process is described in greater detail in Appendix A and that discussion is incor- 
porated herein by reference. Briefly, agent 150A is isolated (0 by voiding all references within agent 150A to 
other processes, and to objects owned by other processes, and (ii) by voiding within all other processes ref- 
erences to agent 1 50A and to objects owned by agent 150A. Processing transfers from isolate agent step 1416 
(Figure 14B) to exiting step 1418. 

In exiting step 1418, place 220A (Figure 15A) notes the departure of agent 150A by performing operation 
"exiting" at the request of engine 132A. Operation "exiting" is described below in greater detail. Processing 
transfers from exiting step 1418 to a next hop is here test step 1420. 

In next hop is h re test step 1420, engine 132A(Figur 15A) compares the transfer destination determined 
in route agent step 1414 (Figur 14B) to the current engine, i.e., engine 1 32A (Figure 1 5A). If the transf r des- 
tination is the current engin , i.e., engine 1 32A, processing transfers from next hop is here test step 1420 (Fig- 
ure 14B) to deliver agent step 1422. In the illustrative example of Figures 15Ar15E, agent 1 50A is transferred 
to engine 132Z, as discussed below; thus, the transfer destination is n t th current engine, i.e., engine 132A 
and processing does not transfer to deliver agent step 1422 (Figure 14B). However, d liver agent step 1422 
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and the steps which follow are described for completeness. 

In deliver agent step 1422, agent 1 50A (Figure 1 5A) is delivered to a place within engine 1 32A which sat- 
isfies ticket 1306 (Figure 13A). D liv ragentstep 1422 (Figure 14B) is represented by logic flow diagram 1422 
(Figure 14E) and is discussed in greater detail below. Processing transfers from deliver agent step 1422 (Figure 
5 1 4B) to a first exception test step 1424 in which engine 1 32A(Figure 1 5A) determines whether delivery of agent 
1 50A threw an exception. If no exception is thrown in deliver agent step 1422 (Figure 14B), processing transfers 
from first exception test step 1424 to terminal step 1428. Terminal step 1428 completes move step 1410 and 
so processing transfers to terminal step 1412 (Figure 14A) which is described above. 

If, on the other hand, an exception is thrown in deliver agent step 1422 (Figure 14B), processing transfers 
10 from first exception test step 1424 to step 1426 in which agent 150A is delivered to purgatory according to 
logic flow diagram 1422 (Figure 14E). Purgatory is a place within each engine and which never denies ingress 
to a process. In entering purgatory, the local permit of agent 150A can be severely restricted. For exampl , 
property "canGo" of the local permit is set to "true" and properties "canCharge", "canCreate", "canDeny", "can- 
Grant", "canRestart", "canSend" and "canTerminate" are set to "false". Properties "charges" and "age" are set 
15 just large enough that agent 150A can detect and analyze the exception that sent agent 150 A to purgatory, 
and can travel to another place by performance of operation "go". The various properties of a permit are de- 
scribed in greater detail in Appendix A. 

Processing transfers from step 1426 to terminal step 1428 and so effectuate move step 1410 (Figure 14A), 
completes successfully, as described above. 
20 As discussed above, if the transfer destination determined in route agent step 1414 (Figure 14B) is the 

current engine, i.e., engine 132A, processing transfers from next hop is here test step 1420 (Figure 14B) to 
deliver agent step 1422. Conversely, if the transfer destination Is not the current engine, processing transfers 
from next hop is here test step 1420 to a form destination step 1430. In form destination step 1430, a destination 
object which specifies the transfer destination is formed. Processing transfers from form destination step 1 430 
25 to encode agent step 1432. 

In encode agent step 1432, engine 132A (Figure 15A) encodes agent 150A according to the encoding rules l ' 
of the Telescript Encoding Rules, included as Appendix B, which is a part of this disclosure and which is incor- *' 
porated herein by reference in its entirety. Encoding agent 150A results in (i) agent 150A, (ii) all objects owned 
by agent 150A including objects 140 A and 140B and (iii) the classes of which agent 150Aand all objects owned 
30 by agent 1 SOAare members being represented in encoded agent 150A-E (Figure 1 5B) in a standardized binary < 
form. The destination object formed in form destination step 1430 (Figure 14B), i.e., destination object 150A- < 
E-D (Figure 21), is included in encoded agent 150A-E and is discussed in greater detail below. As shown in * 
Figure 15B, encoded agent 150A-E is stored in communication infrastructure 132A-CI of engine 132A. Agent 
1 50A (Figure 1 5A) is retained by engine 1 32A until the transfer of encoded agent 1 50A-E is complete as de- 
35 scribed below in greater detail. 

Processing transfers from encode agent step 1432 to transfer out step 1434. In transfer out step 1434, 
engine 1 32A (Figure 15B) initiates transfer of encoded agent 150A-E according to the destination object formed 
in form destination step 1430 (Figure 14B). In this example, the destination object specifies engine 132Z (Fig- 
ure 15B) as the transfer destination of encoded agent 150A-E. Encoded agent 150A-E is transferred as ordi- 
40 nary binary data from communications infrastructure 132A-CI, across communications link 102AZ, to com- 
munications infrastructure 1322-CI of engine 132Z. The transportation of data between communications in- 
frastructures 132A-CI and 132Z-CI is described in greater detail in Appendix C which is a part of this disclosure 
and Appendix F which is incorporated herein in its entirety by reference. As discussed above, the transfer of 
encoded agent 150A-E is initiated in transfer agent out step 1434. Processing according to logic flow diagram 
45 141 0 (Figure 14B) by program portion 132A-P of engine 1 32A proceeds while the transfer of encoded agent 
150A-E between communications infrastructures 132A-CI and 1322-CI continues. 

Processing transfers from transfer out step 1434 to a second exception test step 1436 in which engin 
1 32A determines whether transfer out step 1434 threw an exception, i.e., whether initiation of the transfer of 
encoded agent 150A-E failed. If transfer out step 1434 fails, processing transfers from second exception test 
so step 1426 in which agent 150A is delivered to purgatory as described above. Conversely, if transfer out step 
1434 succeeds, processing transfers from second exception test step 1436 to step 1438. 

In step 1438, ngine 1 32A (Figure 1 5B) adds agent 150A to a list of pending transfers. Agent 132A is re- 
tained in the list of pending transfers during the transfer of ag nt 1 50A. When the transfer is complete, agent 
1 50A is removed from the list of pending transfers and discarded by engine 132A. If the permit of agent 150A 
55 xpires while agent 150A is still on the list of pending transfers, i.e., if the actual age of agent 150A reaches 
property "age" of the effective permit of agent 150A, the transfer of ncoded agent 150A-E is aborted; agent 
150A is removed from th list of pending transfers; and agent 150A throws an exception of class "Permit Ex- 
pired", th reby failing to perform op rati n "go" successfully. Th "eff ctive permit" of a process is described 

25 
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in greater detail in Appendix A. Processing transfers from step 1438 to terminal step 1428 in which logic flow 
diagram 1410 (Figure 14B), and therefore effectuate mov step 1410 (Figure 14A), completes. 

As d scribed above, in route agent step 1414, engine 1 32A (Figure 1 5A) determines the transfer destin- 
ation for agent 150A. Logic flow diagram 1414 (Figure 14C) shows the steps carried out in route agent step 
5 1414 (Figure 14B). 

The following discussion of logic flow diagram 1414 (Figures 14C and 14D) considers circumstances be- 
yond the scope of the illustrative example of Figures 1 5A-1 5E. Logic flow diagram 1 414 (Figures 1 4C and 14D) 
is therefore described independently of the illustrative example of Figures 15A-15E. To provide a framework 
for discussion, however, logic flow diagram 1414 (Figures 14C and 14D) is described in the context of agent 

10 1 50A (Figure 1 5A) performing operation "go" to effectuate a trip which originates in place 220A within engine 
1 32A. The discussion of logic flow diagram 1414 (Figures 14C and 14D) is not limited to (i) a trip in which agent 
150A is transferred to an engine other than engine 132A (Figure 15A) or (ii) a network in which engines 132A, 
1 32Z and 132B are of the same region. Furthermore, the following discussion does not limit ticket 1306 (Figure 
13A), which defines the trip taken by agent 150A (Figure 15A), to either including or excluding specification 

15 of a way, a means, a telename, or a provider. Ticket 1306 (Figure 13A), in the context of logic flow diagram 
1414 (Figures 14C and 14D), can define a trip (i) to a place within engine 132A (Figure 15A), (ii) to a place 
within an engine in the same region as engine 132A, or (iii) to a place within an engine in a region different 
than the region which contains engine 132A. 

Recall that for operation "go", ticket 1306, which is consumed as an argument to operation "go", specifies 

20 the destination and other characteristics of the trip. In logic flow diagram 1414, engine 132A (Figure 15A) in 
test step 1440 queries attribute "way" of ticket 1306 (Figures 13 and 18A), thereby producing property "way" 
of ticket 1306. Property "way" of ticket 1306 is way 1820 (Figure 18A). Property "way" of ticket 1306 Is optional 
and can therefore alternatively be a nil (not shown). 

If property "way" of ticket 1306 is a nil, processing transfers from test step 1440 to a ticket has provider 

25 test step 1460 which is described below in greater detail. Conversely, if property "way" of ticket 1 306 is a way, 
i.e., is notanil, processing transfers from test step 1440 to step 1442 in which engine 132A (Figure 15A) queries 
attribute "name" of way 1820 (Figure 18A), thereby producing the telename that is property "name" of way 
1820. Also in step 1442 (Figure 14C), engine 132A (Figure 15A) produces and copies property "authority" of 
that telename. The resulting "authority", which is represented by an octet string as described in Appendix A, 

30 is used to determine the transfer destination, as described below. 

Processing transfers from step 1442 to a way has means test step 1444 (Figure 14C) in which attribute 
"means" of way 1820 (Figure 18B) is queried, thereby producing property "means" of way 1820, which is means 
object 1822. Property "means" is optional and can therefore alternatively be a nil (not shown). 

A means object, i.e., a member of class "Means", is an object which specifies an engine by specifying (i) 

35 an intercomputer communications medium and (ii) transfer instructions to reach a specific engine via that me- 
dium. For example, a means object can specify the public switched telephone network (PSTN) and specify 
modem instructions which include the telephone number of a specific modem through which to transfer the 
agent to a destination engine. As a means object contains all information needed to route agent 150A to a des- 
tination engine, other properties of ticket 1306 are ignored if ticket 1306 contains a means object 

40 Therefore, if property "means" of way 1820 is not nil, i.e., is means object 1822 (Figure 18B), processing 

transfers from way has means test step 1444 (Figure 14C) to step 1446. In step 1446, way 1 820 is designated 
as the way which defines the transfer destination. It should be noted that means object 1822 defines the engine 
that is the destination of the first hop, i.e., the first transfer of agent 1 50A (Figure 1 5A), and not the destination 
of the trip defined by ticket 1306 (Figure 18A), which is necessarily a place rather than an engine. Processing 

45 transfers from step 1446 to terminal step 1448 in which the processing of logic flow diagram 1414, i.e., route 
agent step 1414 (Figure 14B), completes successfully. 

Conversely, if property "means" of way 1820 (Figure 18B) is nil, way 1820 contains no means object and 
processing transfers from way has means test step 1444 (Figure 14C) to a ticket has name test step 1450. In 
ticket has name test step 1450, engine 132A (Figure 15A) produces property "destinationName" of ticket 1306 

so (Figure 18A), which is telename 1818, and compares telename 1818 to a nil. As property "destinationName" 
of ticket 1306 is optional, property "destinationName" of ticket 1306 can be a nil (not shown). 

If property "destinationName" of ticket 1306 is a nil, processing transfers from ticket has name test step 
1450 to tick t has provider test step 1460, which is described below. Convers ly, if property "destinati nName" 
of ticket 1306 is telename 1 818, processing transfers from ticket has name test step 1450 to step 1452. In step 

» 1452, engin 132A (Figure 15A) produces a way bject which defines a transfer path for agent 150A to the 
transfer destination. Engine 132A consults a find r, which is described in greater detail below, to produce a 
way object to a region associated with th authority produced and copied in step 1442 (Figure 14C) above, 
and a place within that auth rity whose name is equal to t lename 1818 (Figure 1 8A) . The production of such 
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a way object by use of a finder is described in great r d tail below. 

Processing transfers from step 1452 to a way out is here test step 1454 in which engine 132A (Figure 15A) 
determines whether the way object produced in step 1452 (Figure 14C) defines a transfer to engine 132A (Fig- 
ure 15A). If the produced way object does not define a transfer to engine 132A, processing transfers from way 
5 out is here test step 1454 to terminal step 1456 in which the processing of logic flow diagram 1414, i.e., rout 
agent step 1414 (Figure 14B), completes successfully. 

Conversely, if the produced way object defines a transfer to engine 1 32A (Figure 1 5A), processing trans- 
fers from way out is here test step 1454 to step 1458 in which engine 1 32A sets a flag indicating that agent 
150A is to be transferred to engine 132A. Processing transfers from step 1458 to a second ticket has name 
10 test step 1480 which is described below in greater detail. 

As discussed above, if property "way" of ticket 1 306 is nil, processing transfers from ticket has way test 
step 1440 to ticket has provider test step 1460. In ticket has provider test step 1460, engine 132A produces 
property "destinationAddress" of ticket 1306, which is a teteaddress 1814 (Figure 18A), and produces property 
"provider" of teleaddress 1814. If either property "destinationAddress" of ticket 1306, or property "provider" of 
15 teleaddress 1814, is a nil, processing transfers from ticket has provider test step 1460 to second ticket has 
name test step 1480, which is described below in greater detail. Conversely, if property "destinationAddress" 
of ticket 1306 (Figure 18A) and property "provider" of the teleaddress 1814 are not nil, ticket 1306 specifies 
a region which contains the trip destination and processing transfers from ticket has provider test step 1460 
to step 1462. 

20 In step 1462, engine 1 32A (Figure 15A) consults a finder, as described below in greater detail, to produce 

a way object which defines a transfer to an engine of a region denoted by property "provider" of property "des- 
tinationAddress" of ticket 1306. Processing transfers from step 1462 (Figure 14C) to a first found test step 1464 
in which engine 132A (Figure 15A) determines whether a way object is successfully produced in step 1462. If 
a way object is produced in step 1462, processing transfers from first found test step 1464 to a second way 

25 out is here test step 1472, which is described in greater detail below. Conversely, if no way object is produced 
in step 1462, processing transfers from first found test step to step 1466. 

In step 1466, engine 132A (Figure 15A) consults a finder, as described below in greater detail, to produce * 
a way object which defines a transfer to a region denoted by an item of property "routingAdvice" of the tele- 
address that is property "destinationAddress" of ticket 1306. The properties of a teleaddress, and properties 

30 "provider" and "routingAdvice" in particular, are described in greater detail in Appendix A, and that discussion " 
is incorporated herein by reference. Briefly, the items of property "routingAdvice" of a teleaddress denote pro- 
viders of zero or more regions which are believed by the creator of the teleaddress to be capable of transferring 
agent 150A to the trip destination defined by ticket 1306 (Figure 18A). Processing transfers from step 1466 * 
(Figure 14C) to a second found test step 1468 in which engine 1 32A (Figure 15A) determines whether a way 

35 object is successfully produced in step 1466. If no way object is produced in step 1466, processing transfers 
from second found test step 1468 to terminal step 1470 in which an exception of class "Destination Unavailabl " 
is thrown. Conversely, if a way object is produced in step 1466, processing transfers from second found test 
step 1468 to second way out is here test step 1472. 

In second way out is here test step 1472, engine 132A (Figure 15A) determines whether the way object 

40 produced in either step 1462 or step 1466 (Figure 14C) defines a transfer to engine 132A (Figure 15A). If th 
produced way object does not define a transfer to engine 1 32A, processing transfers from second way out is 
here test step 1472 to terminal step 1474 in which the processing of logic flow diagram 1414, i.e., route agent 
step 1414 (Figure 14B), completes successfully. 

Conversely, if the produced way object defines a transfer to engine 1 32A (Figure 1 5A), processing trans- 

45 fers from second way out is here test step 1472 to step 1476 in which engine 132A (Figure 15A) derives a tel- 
ename, which identifies the destination of the trip defined by ticket 1306, from property "location" of the tel- 
eaddress that is property "destinationAddress" of ticket 1 306. 

Engine 132A can derive the telename in any way which is convenient and efficient. For example, engine 
132A can use a table such as dictionary 2000 (Figure 20A) whose keys are octet strings, e.g., octet string 

so 2000K1 , and whose values are telenames, e.g., telename 2000V1 . For example, if property "location" of tel- 
eaddress 1814 (Figure 18A) equals octet string 2000K1 (Figure 20A), telename 2000V1 is produced by engine 
1 32A as the telenam that specifies a place that is the destination of th trip defined by tick 1 1 306 (Figure 
18A). 

Addresses are assigned to locations within a region according to an addressing schem designed and im- 
ss plemented by th designer and implementer of the engines of the region. Th disclosed instruction set does 
not prescribe a particular addressing scheme. Each region is f re to implement the most efficient and conve- 
nient addressing scheme for that particular region. Thus, as each sovereign state in the physical world designs 
and implements its own addressing scheme in providing a postal service, each region is free to implement a 

27 



RNSDOOID: <EP 0&U71QA9 I » 



EP 0 634 719 A2 



20 



25 



unique addressing scheme for that region. Of course, the addressing schemes used within two or more regions 
need not be unique. 

In implementing an addressing scheme, engines of a region assign teieaddresses to locations which in- 
clude one or more places. In assigning a teleaddress, an engine produces and stores a telename which spe- 

s cifies one or more of the places within the location specified by the teleaddress. In other words, an engine, 
which assigns teieaddresses, maintains information which links teieaddresses to telenames of places to which 
respective teieaddresses are assigned. In this way, an engine, e.g., engine 132A (Figure 15A), can produce a 
telename of a place having a specified teleaddress. The particular mechanism by which such a telename is 
stored and produced is left up to the person or organization which designs and implements the engines of a 

10 given region. 

Processing transfers from step 1476 to step 1478 in which engine 132A (Figure 15A) sets a flag indicating 
that agent 150A is to be transferred to an engine within the region which contains engine 132A. Processing 
transfers from step 1478 (Figure 14C) to second ticket has name test step 1480 (Figure 14D). Processing also 
transfers to second ticket has name test step 1480 from step 1458 (Figure 14C) and from ticket has provider 
is test step 1460, both of which are described above in greater detail. 

In second ticket has nameteststep 1480 (Figure 14D), engine 1 32A (Figure 15A) determines whether prop- 
erty "destinationName" of ticket 1306 (Figure 18A), is a nil or telename 1818. If property "destinationName" 
of ticket 1306 is telename 1818, processing transfers from second ticket has name test step 1480 (Figure 14D) 
to step 1482 in which engine 132A (Figure 15A) produces a copy of telename 1818 (Figure 18A) and the copy 
supersedes the telename derived in step 1476 (Figure 14C) as the telename of the transfer destination. Proo- 
essing transfers from step 1482 (Figure 14D)tostep 1483. Additionally, if property "destinationName" of ticket 
1306 is a nil, processing transfers from second ticket has name test step 1480 directly to step 1483. 

In step 1483, engine 132A (Figure 15A) consults a finder, as described below in greater detail, to produce 
a way object which defines a transfer to a place denoted by the telename produced in either step 1476 (Figur 
14C) or step 1482 (Figure 14D) as described above. Processing transfers from step 1483 to test step 1484 in 
which engine 1 32A (Figure 15A) determines whether step 1458 (Figure 14C) sets the flag which indicates that 
the destination of the transfer is engine 1 32A (Figure 1 5A). If the flag is not set, processing transfers from test 
step 1484 to test step 1490 which is described below. Conversely, if the flag is set, the transfer of agent 150A 
(Figure 15A) should be to a place within engine 132A and processing transfers from test step 1484 (Figure 
30 14D) to a third way out is here test step 1486. 

In third way out is here test step 1486, engine 1 32A (Figure 1 5A) determines whether the way object pro- 
duced in step 1483 (Figure 14D) defines a transfer to engine 132A (Figure 15A). If the produced way object 
does not define a transferto engine 132A, processing transfersfrom third way out is here test step 1486 (Figure 
14D) to terminal step 1488 in which an exception of class "Destination Unavailable" is thrown and processing 
35 according to logic flow diagram 1414 (Figures 14C and 14D), i.e., route agent step 1414 (Figure 14B), com- 
pletes. Conversely, if the produced way object defines a transfer to a place within engine 1 32A (Figure 1 5A), 
processing transfers from test step 1486 (Figure 14D) to test step 1490. 

In test step 1490, engine 1 32A (Figure 15A) determines whether step 1478 (Figure 14C) sets the flag which 
indicates that the destination of the transfer is the region which includes engine 1 32A (Figure 1 5A). If this flag 
is not set, processing transfers from test step 1490 to terminal step 1496 in which processing according to logic 
flow diagram 1414 (Figures 14C and 14D), i.e., route agent step 1414 (Figure 14B), completes successfully 
Conversely, if the flag is set, the transfer of agent 150A (Figure 15A) should be to a place within the region 
which includes engine 1 32A and processing transfers from test step 1490 (Figure 14D) to way out is this region 
test step 1492. In way out is this region test step 1492, engine 1 32A (Figure 1 5A) determines whether the way 
object produced in step 1483 (Figure 14D) defines a transfer to a place within the region which includes engine 
132A (Figure 15A). If the produced way object does not define a transfer to a place within the region which 
includes engine 132A. processing transfers from way out is this region test step 1492 (Figure 14D) to terminal 
step 1494 in which an exception of class "Destination Unavailable" is thrown and processing according to logic 
flow diagram 1414 (Figures 14C and 14D), i.e., route agent step 1414 (Figure 14B), completes. 

As discussed above with respect to steps 1452, 1462, 1466 and 1483 (Figure 14C), engine 132A (Figure 
132A) uses a finder to route agent 150A in a transfer toward a destination of the trip defined by ticket 1306 
(Figure 1 3A). Af inder is used to determin the transfer destination for an ag nt. For example, ticket 1 306 (Fig- 
ure 13A) defin s place 220B (Figure 15A) within engin 132B as a destination of the trip. However, to reach 
engine 132B, agent 150A must first be transf rred to engine 132Z, which is therefore the transfer destination 
Finder 2050 (Figure 20B) is used to produce a telename of an engine that is a transfer destination toward a 
place, which is identified by a second telename. In one embodiment, the produced telename identifies an en- 
gine by identifying the engine place process d by the ngine. Th second t lename can identify a specific 
place or an auth rity,. thereby specifying all places of the identified authority. Telenames are described in 
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greater detail in Appendix A. 

In th context of st p 1452 (Figure 14C) t the s cond tele name is t lenam 1818 (Figure 18A), which is 
property "destinationName" of ticket 1306. If finder 2050 (Figure 20B) contains n information regarding tele- 
name 1 818, the second telename, in the context of step 1452 (Figure 14C), is a telename which identifies the 
authority produced and copied in step 1442 as described above. In the context of step 1462, the second tele- 
name identifies the authority specified in property "provider" of teleaddress 1814 (Figure 18A) of ticket 1306. 
In the context of step 1466 (Figure 14C), the second telename identifies the authority specified in an item of 
the list that is property "routingAdvice" of telename 1814 (Figure 18A) of ticket 1306. In the context of step 
1483 (Figure 14D), the second telename is either telename 1818 (Figure 18A) of ticket 1306, if property "des- 
tinationName 0 of ticket 1306 is not nil, or the telename produced in step 1476 (Figure 14C), otherwise. Finder 
2050 (Figure 20B) is described below in the context of step 1483 (Figure 14D) in which the second telename 
is telename 1818 (Figure 18A) of ticket 1306. 

In each of steps 1452 (Figure 14C), 1462, 1466, and 1483 (Figure 14D), the telename produced by use of 
finder 2050 (Figure 20B) is used to form a way object which defines a transfer to the engine identified by the 
produced telename. 

Engine 1 32A determines to which engine to transfer agent 1 50A, i.e., the "transfer destination", by use of 
a finder 2050 (Figure 20B). Finder 2050 can be any data structure which allows engine 132Ato determine, 
from a trip destination, a transfer destination that moves agent 150A toward the trip destination. In one em- 
bodiment, finder 2050 is a dictionary whose keys are telenames and whose values are also telenames. The 
keys, e.g., telenames 2050K1-2050K6, specify authorities. The values, e.g., telenames 2050V1-2050V6, iden- 
tify engines through which places identified by each respective corresponding authority can be reached. If 
telename 2050K1 (Figure 20B) of finder 2050 has the same authority as that of telename 1818, telename 
2050V1 identifies engine 132Z as the transfer destination. 

In one embodiment of the present invention, the keys of finder 2050 include a nil 2050K7, which is asso- 
ciated with a telename 2050V7. Telename 2050V7 identifies an engine which contains information regarding 
a substantial portion of network 1500 (Figure 15A) and networks to which network 1500 can be connected, 
either directly or indirectly. The engine which is identified by telename 2050V7 is therefore more likely to have 
success in routing agent 1 50A toward a trip destination which satisfies ticket 1306 (Figure 18A) . If no telename 
which is a key of finder 2050 (Figure 20B) is of the same authority as telename 1 81 8, telename 2050V7 (Figure 
20B), which is associated with nil 2050K7, identifies the transfer destination. The following example is illus- 
trative. 

Suppose, for example, that engine 132A is executing within a small personal computer system and there- 
fore interprets places of only one authority. Suppose further that engine 132Z (Figure 15A) is executing within 
a large, multi-user, mainframe computer system which interprets places of many separate authorities and to 
which many agents of many different authorities travel. The finder of engine 132A would, in such a case, be 
very small and provide little information regarding the transportation of agents to places of particular author- 
ities. However, the finder of engine 1 32Z is likely to be much more extensive and comprehensive, and therefor 
much more likely to provide information regarding the routing of a particular agent to places of particular au- 
thorities. In such a case, the finder of engine 132A associates with a nil a telename which identifies engin 
1 32Z as the transfer destination when the finder of engine 1 32A contains no information regarding the authority 
of the trip destination place. 

If no transfer destination is successfully determined from consulting finder 2050 (Figure 20B), an engine 
can implement any of the following or other policies according to the implementation chosen by the provider 
of the engine. If ticket 1306 (Figure 18A) contains citation 1816, engine 132A (Figure 15A) can (i) produce a 
telename to the current place of agent 1 50A and attempt to find a place of the cited class in the steps described 
below, (ii) throw an exception and produce no telename, thereby rejecting ticket 1306 (Figure 18A) as vague, 
or(iii) produce a telename of a place which is designated as a destination of vaguely specified trips. Similarly, 
if ticket 1306 includes no citation, engine 132A (Figure 15A) can (i) throw an exception and produce no tele- 
name, thereby rejecting ticket 1306 (Figure 18A) as vague, or (ii) produce a telename of a place which is des- 
ignated as a destination of vaguely specified trips. 

In the example of Figures 15A-15E, engine 132A (Figure 15A) consults finder 2050 (Figure 20A) and de- 
termines that, to reach place 220B (Figure 15A) of engine 132B, agent 150A is to be transferred to ngine 132Z. 
Th refore, the engine place of engine 1 32Z is the transfer destination of agent 150A and a way object, which 
defines a transfer of agent 150A to engine 132Z, is produced. 

Thus, processing according to logic flow diagram 1414 (Figures 14Cand 14D) produces a way object which 
defines a transfer of agent 150A (Figure 15A) to move agent 150A toward the destination of the trip d fined 
by ticket 1306. 

As discussed ab v in the context of logic flow diagram 1410 (Figure 14B), agent 150A (Figure 15A) is 
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in transfer out step 1434 (Figure 14B). Appended to encoded agent 150A-E (Figure 21) is destination 150A- 
E-D, which includes properties °nam "addr ss° and "data" which ar telename 2102, teleaddress 2104 and 
octet string 2106, respecttv ly. Telename 2102 and teleaddress 2104 define the transfer destination of encod- 
ed agent 15 OA- E. The transfer destination as defined by destination 150A-E-D (Figure 21) can be either engine 

5 1322 (Figure 15B) or engine 132B. In one embodiment of the present invention, destination 150A-E-D (Figure 
21), which is formed inform destination step 1430 (Figure 14B), defines engine 132Z (Figure 15B) as the trans- 
fer destination of encoded agent 150A-E. In that case, communications infrastructure 132A-CI transfers en- 
coded agent 150A-E directly to communications infrastructure 1322-CI of engine 132Z. In another embodi- 
ment ofthe present invention, destination 150A-E-D (Figure 21) defines engine 1 32 B (Figure 15B) asthetrans- 

10 fer destination of encoded agent 150A-E. In the latter case, communications infrastructure 132A-CI contains 
information and logic which causes communications infrastructure 132A-CI to transfer encoded agent 150A- 
E, which is destined for engine 132B according to destination 150A-E-D (Figure 21), to communications infra- 
structure 132Z-CI (Figure 15B) or engine 132Z. 

In either embodiment described above, when engine 132Z (Figure 15C) receives encoded agent 150A-E, 

is engine 1 32Z performs a system operation determined in route agent step 1414 "transferln 0 which is shown as 
logic flow diagram 1400-1 (Figure 14F). Engine 132Z (Figure 15C) begins performance of system operati n 
"transferin" by producing a way object which defines a transfer to destination 150A-E-D (Figure 21) in step 
1402-1 (Figure 14F). Engine 132Z produces a way object in step 1402-1 (Figure 14F) by consulting a finder 
within engine 132Z (Figure 15C) as described above with respect to finder 2050 (Figure 20B). 

20 Processing transfers from step 1402-1 (Figure 14F) to a fourth way out is here test step 1404-1 in which 

engine 132Z (Figure 15C) determines whether the way object produced in step 1402-1 (Figure 14F) defines a 
transfer to engine 132Z (Figure 1 5C). If the produced way object does not specify engine 132Z (Figure 15C) 
as the transfer destination, i.e., if destination 150A-E-D (Figure 21) defines engine 132B (Figure 15B) as th 
transfer destination, processing transfers from fourth way out is here test step 1404-1 (Figure 14Fs) to a second 

25 transfer out step 1406-1. In second transfer out step 1406-1, engine 132Z (Figure 15C) initiates transfer of en- 
coded agent 150A-E according to destination 150A-E-D (Figure 21) in a manner directly analogous to that de- 
scribed above with respect to transfer out step 1434 (Figure 14B). 

Processing transfers from second transfer out step 1406-1 to step 1408-1. In step 1408-1, engine 1322 (Fig- 
ure 15C) adds encoded agent 150A-E to a list of pending transfers as described above with respect to step . 

30 1438 (Figure 14B). Processing transfers from step 1408-1 (Figure 14F) to terminal step 1410-1 in which system 
operation "transferin" completes successfully. 

Thus, if the way object produced in step 1402-1 defines a transfer to engine 132B (Figure 15C), encoded 
agent 150A-E is transferred according to the produced way object. If, on the other hand, the produced way 
object defines a transfer to engine 1 32Z, processing transfers from fourth way out is here test step 1404-1 (Fig- 

35 ure 14F) to step 1412-1. Instep 1412-1, engine 1322 (Figure 15C) extracts from encoded agent 1 50A-E ticket 
1306 (Figures 13A and 18A) and forms a copy of ticket 1306. Processing transfers from step 1412-1 to step 
1414-1 in which property "way" of the ticket copy is cleared, i.e., set to a nil. Processing transfers from step 
1414-1 to a second route agent step 1416-1 in which engine 132Z produces a way object defining a transfer of 
encoded agent 150A-E. The process performed in step 1416-1 is identical to the process represented by logic 

40 flow diagram 1414 (Figures 14C and 14D). In the context of second route agent step 1416-1, ticket 1 306 used 
in the above discussion of logic flow diagram 1414 is replaced by the ticket copy made in step 1412-1, and the 
logic flow diagram is processed as described above using the ticket copy. Upon completion of step 1416-1, 
processing transfers to a fifth way out is here test step 1418-1. 

In fifth way out is here test step 1418-1, engine 1322 (Figure 15C) determines whether the way object pro- 

45 duced in step 1416-1 (Figure 14F) defines a transfer to engine 1 322 (Figure 15C). If the produced way object 
defines a transfer to engine 132Z, processing transfers from fifth way out is here test step 1418-1 (Figure 14F) 
to a decode agent step 1 428-I which is described below in greater detail . Conversely, if the produced way object 
does not define a transfer to engine 1322 (Figure 15C), processing transfers from fifth way out is here test 
step 1418-1 (Figure 14F) to a second form destination step 1420-1. In the example of Figures 15A-15F, ticket 

so 1306 (Figure 13A), which is extracted from encoded agent 150A-E and copied, defines a trip to place 220B 
of engine 132B (Figure 15C). Therefore, processing transfers to second form destination step 1420-1. 

In form destination step 1420-1, engine 1322 (Figure 15C) forms, i.e., supersedes, destination 150A-E-D 
(Figure 21 ) in a manner that is directly analogous to that described above with respect to form destination step 
1430 (Figure 14B). Processing transfers from sec nd form destination step 1420-1 (Figure 14F) to a third trans- 

55 fer outstep 1422-1. In third transfer out st p 1422-1, encoded agent 150A-E (Figure 15C) is transferred accord- 
ing to destination 150A-E-D (Figure 21) as described above with resp ct to second transfer ut step 1406-1 
(Figure 14F). 

Processing transfers from third transfer out step 1422-1 to step 1424-1. In step 1424-1, engine 1322 (Figure 
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1 SO) adds encoded agent 1S0A-E to a list of pending transfers as described abov with respect to step 1438 

LrlZ 1™L h^'" 9 f StSP 1424 "' (Fi9ure 14F) to 1 rminal ste P 1426 -« whfch system op- 

erate Iransferln" compl tes successfully. In th exampl of Figures 15A-15F, encoded agent 150A-E is 
transferredfrom engine 1322 to engine 132B (Figure 15D) in a mannerthat is directly analogous to the transfer 
of encoded agent 150A-E from engine 132A to engine 132Z as described above. 

Operation "Go" from th e Perspective of the Destination Engine 

When engine 132B receives encoded agent 150A-E in communication infrastructure 132A-CI (Figure 
SyStem Cperation " transferi n" -n a manner similar to that described above with 

'especttoeng^ 
toenSeTa^ 

Sil ( ? 1,2 ^ W8y ° Ut iS h6re tSSt Step 1404 -' < Fk J ure 14F >- Since engine 1 32B (Figure 

15D) processes place 220B wh.oh is the destination of the trip defined by ticket 1306 (Figure 13A). the pro- 
duced way objectdefines a transferto engine 132B (Figure 15D). Therefore, processing by engine M32B tra^ 
fers from fourth way out is here test step 1404-1 (Figure 14F) to step 1412-1 

Insteps 1412-1. 1414-1 and 1416-1, engine 132B extracts and copies ticket 1306 (Figure 13A)from encoded 
^6^^?^ Pe Z? ar ° f ^ tiCkSt C ° Py> and r ° UteS 6ncoded ^enMS^OA-E acc.ZgT?4lc 
J^Lt TT?- 1 { ,9UTeS 14C and 14D) SXCept nOW tne fcket °°W is used for «<*et 1 306 in the above ^Je- 

thTwav oSI^Z^ " ?* St6P 1418 "' <Fi9Ure 14F) ' e " 9ine 1326 (Fi9ure 15D > ^termines whether 
,» «™ i? P"*"^ ln «** agent step 1416-1 (Figure 14F) defines a transferto engine 132B (Fig- 

to engine ^Tre 35 S"", 15D) PraC8 f eS P ' aCe 220B ' tne p,odU0Bd way ob *« def ' nes a 
ItoSSISin f h T ^ refore - P^^'ng by engine 132B transfers from fifth way out is here test 
step 1418-1 (Figure 14F) to decode agent step 1428-1. 

In decode agent step 1428-1, engine 132B decodes agent 150Afrom encoded agent 150A-E (Figure 15D) 

B a^dTT ° n f^T"*^ 132B " CI by app,iCati0 " ° f the encodi "9 rutes Oescnbed in Appendix 

foZ If ™, S ♦! ^ POrti ° n 132B_D <R9Ure 15E) - * network 1500 ^ be heterogeneous, th 
endne l l^ ntutTp? IT' 132A < Figure 15A > mav te inconvenient for representing agenT 150A within 

vfnltt^r e " 9 ™ 132B ' en9ine 1328 03,1 repreaent agent 150Ain whatever form is most Con- 

venient for engine 1 32B when not transferring agent 150A. 

i^rr, 08 !! 8 !" 9 by en9ine 1328 t,anSferS fr ° m decode a 9 ent ste P 1428 -' <F*«» 14F) to deliver agent step 
1430-I. In deliver agent step 1430-1, agent 150Ais delivered according to logic flow diagram 1422 (Figure 14E) 

^rTh^^ 6 With f . reSpect to deliver a 9 fint 8te P 142 2 (R9ure 14B). In the context of deliver agent step 

^iT 9 ?%' n T 150A < F «9^ 15E) is granted occupancy in place 220B and operation "go" as per- 
formed by agent 150A completes successfully. * ^ 
Processing transfers from deliver agent step 1430-1 (Figure 14F) to terminal step 1426-1 in which process- 

Z^S^ '°f/ ,OW di39ram 14 °°-' (R9Ure 14F) - ie - Prance of system operation ^ransferin"^ 
engine 132B completes successfully. ■=■■», uy 

Any exception thrown in the course of performing the steps of logic flow diagram 1400-1 (Figure 14F) caus- 

L P „ e tT^ a p?P ,09iCf, ° Wdia9ra,n 145 °-' (Rgure 14 G)- Agent 150A is decoded from encoded 

™ iS* ( ? U Z ? m 1 6P 1452 -' (Fi9Ure 14F) - Since agent 15n Aarrived in engine 132B (Figure 15D), 

Ini^^ 883 ^^^ a9ent 15 ° A 10 COntinue execution <* a 9 ent 150A " Processing transfers from 
step1452-l (Figure 14G) to deliver agent step 1454-1 in which agent 150A is delivered to purgatory as described 

whS rSU? 1488 i" ProCeSSi " 9 aCCOrding to ,ogic f,ow diagram 1450 -' completes. Agent 150A. 
manl^ r^H ^ "«Y!T* * ^ Step 1454 -'' the exception «■** caused perforl 

mance of log,c flow diagram 1450-1. thereby causing operation "go" as performed by agent 1 50A to fail 

Thus.agent150A(Figures15A-15E).byperfbrrnanceofo P eration^di re ctsmovement ie transoor- 

^oo^V 5 ^ and ,° bJeCtS ° wned by a9ent 150A "* 88 °* « s 140A and l^-S'h^ZSi 
; JJ? P^°""ance of operation "go", interpretation of agent 150A continues with th instruction within 
agent 150A which immediately follows operation "go". 

lowiS!^;!! ShOWS , 8 P ° rt i- " °1 the XeCUti ° n State and * the internal state f a 9ant 150A immediately fol- 
™7 Pf^^nce^eperahon "go" by agent 150A. At the top of stack 1304 is ticket stub 1308 which is th 
result produced by p rformance f operation "go". Place 220B is the prop rtyofag nt 150A iderti Ig the 
place occupied by ag nt 150A. thereby indicating that agent 150A occupies place 220B Mentlfym9 the 



32 



PNonnrirv -co rvrxAna/i? i ^ 



EP 0 634 719 A2 

Ingress and Egress: Operations "Ent ring" and "Exiting" 

As discussed above, place 220B grants or denies ingress to agent 1 50A by p rformance of operation "en- 
tering". The embodiment disclosed above with respect to logic flow diagram 1400 (Figures 14A and 14B) trans- 
5 ports encoded agent 150A-E (Figures 15A-15E) to engine 132B before requesting that place 220B perform 
operation "entering". In another embodiment of the present invention, place 220B is directed to perform oper- 
ation "entering" before agent 150A is transported across communications link 102AZ, through communication 
infrastructure 132Z-CI, across communications link 102ZB to engine 132B. By performing operation "enter- 
ing", place 220B either grants or den ies agent 1 50A permission to occupy place 220B. However, it is anticipated 
10 that the present invention will be used in wide-area networks with high latency. 

The term "latency" is used herein as it is used in the art to denote the amount of time between the time 
information is first sent by thesender of the information and the time information is first received by the receiver 
of the information. In networks with high latency, even short messages can require substantial amounts of time 
to reach a destination. In such a case, requesting that place 220B (Figure 15A) perform operation "entering" 
15 and awaiting a result involves sending a request across communications link 102AZ, through communication 
infrastructure 132Z-CI, across communications link 102ZB and through engine 132B to place 220B to perform 
operation "entering" and awaiting receipt of the result produced by operation "entering" by the reverse path. 
Doing so before transporting agent 1 50 A to engine 132B postpones the transportation of agent 150 A to engine 
1 32B by an amount of time approximately equal to twice the latency between engines 1 32A and 1 32B. There- 
20 fore, to substantially improve the performance of the present invention, performance of operation "entering" 
by place 220B is postponed until agent 150A is transported to engine 132B. 

While operation "entering" Is described in the context of agent 1 50A (Figure 15E) entering place 220B as 
a consequence of operation "go", operation "entering" is also performed as a consequence of a process, either 
an agent or a place, entering place 220B as a consequence of the process's creation within place 220B. Th 
25 creation of a process is discussed in greater detail in Appendix A. 

Figure 22A gives the execution state of agent 1 50A immediately prior to performance of operation "enter- 
ing". The execution state of a process, e.g., agent 150 A, is described in greater detail below. Operation "en- 
tering" is performed at the request of engine 132B, and the performance of "entering" is recorded in the exe- 
cution state of agent 150 A (Figure 15E). The permit of either agent 150A or place 220B, preferably place 220B, 
30 may be debited by performance of operation "entering". 

Frame 2200 is part of the execution state of agent 150A and records the dynamic state of operation "en- 
tering" as performed by place 220B. Frame 2200 includes stack 2202 which is the current stack. Stack 2202 
contains, from top to bottom, contact 2208, permit 2206 and ticket 2204. 

Contact 2208 identifies agent 150Aas the process attempting to enter place 220B. As discussed below 
35 in greater detail and in Appendix A, a contact has, among its properties, a property "subjectName" and a prop- 
erty "subject". Property "subject" of contact 2208, which is ordinarily a reference to agent 1 50A, is nil in oper- 
ation "entering" so that place 220B is not given a reference to agent 150A before place 220B grants ingress 
to agent 1 50A. Property "subjectName" of contact 2208 is a telename which identifies agent 1 50A as the agent 
requesting ingress to place 220B. 
40 Permit 2206 is the proposed local permit of the agent attempting to "enter" place 220B. Permit 2206 is 

passed "byProtectedRef" and therefore cannot be altered by performance of operation "entering". The passing 
of arguments and results, and in particular passing by protected reference, i.e., "byProtectedRef 1 , is described 
below in greater detail. An agent's local permit defines the capabilities of the agent while at a given place. For 
example, agent 150A can limit itself to a subset of the capabilities and allowances of its native permit while at 
45 place 220B by supplying to place 220B permit 2206 which defines the subset of capabilities and allowances. 

Ticket 2204 is passed "byProtectedRef" and is equal to ticket 1 306 used to travel to responding place 220B 
and informs responding place 220B that agent 150A is attempting to enter from another place. If ticket 2204 
is a nil, a process is attempting to enter responding place 220B by the process's creation within responding 
place 220B. 

so The method by which a place determines whether to admit a process, i.e., the method implementing op- 

eration "entering", as defined by class "Place" always throws an exception that is a member of class "Occu- 
pancy Deni d", th reby denying the process ingress to the responding place. How ver, users of the present 
invention define subclasses of class "Place" which grant entrance to processes under specific circumstances. 
Such is a practical necessity f r agents to travel from one plac to another. 

55 Asth implementation f operation "entering", as performed by a place, is defined by th particular method 

provided by or inherited by the class of which the place is an instance, each place can implement peration 
"entering" differently from other places in the network. Logic fl w diagram 2260 (Figure 22C) serves as an 
illustrative example of an implem n tat ion of operation "entering" and therefore of the steps taken by place 220B 
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in performance of operation "entering" in entering step 1448 (Figure 14B). 

Contact 2208, permit 2206 and ticket 2204 are popped from stack 2202 in steps 2262, 2264 and 2266, 
respectively (Figure 22C). Processing then transfers to ticket test step 2272 in which ticket 2204 is compared 
to a nil. If ticket 2204 is a nil, agent 150A is being created locally and processing transfers to terminal step 

5 2274 where operation "entering" completes successfully. However, it is apparent in view of the foregoing and 
the following that a place can be defined such that operation "entering" fails under certain circumstances so 
as to prevent the creation of a process within the place. 

If ticket 2204 is not nil, processing transfers from ticket test step 2272 to allowance test step 2276. In al- 
lowance test step 2276, property "charges" of permit 2206 is produced by querying attribute "charges" of permit 

10 2206 and property "charges" of permit 2206 is compared to 1 000. If property "charges" of permit 2206 is greater 
than 1000, processing transfers from allowance test step 2276 to terminal step 2278 where an exception of 
class "Occupancy Denied" is thrown, denying the agent ingress into the responding place. If property "charges" 
of permit 2206 is less than or equal to 1000, processing transfers from allowance test step 2276 to terminal 
step 2274 where operation "entering" terminates successfully, granting the agent ingress into the responding 

is place. The exact number 1000 as a maximum permissible charges allowance in the example of Figure 22C is 
chosen arbitrarily for purposes of illustration. 

The method of logic flow diagram 2260 is illustrative of an appropriate implementation of operation "en- 
tering" for places processed by an engine operating within a personal computer system with limited resources. 
As discussed above and in Appendix A, property "charges" of a permit is an allowance of processing. Thus, 

20 according to logic flow diagram 2260, agents, which indicate by a large charges allowance in their proposed 
local permits a need for large amounts of computation and resources, are denied ingress. Thus, the owner of 
a small personal computer system can restrict her personal computer system to processes created locally and 
to relatively inexpensive visits by agents created elsewhere. 

Immediately following performance of operation "entering" by place 220B (Figure 22B), stack 2202 is emp- 

25 ty as operation "entering" produces no result. 

As discussed above, a place notes the departure, i.e., the termination of occupancy, of a process by per- 
formance of operation "exiting". In the context of logic flow diagram 1400 (Figures 14A and 14B), place 220A 
is performing operation "exiting" as a result of an agent, i.e., agent 160A, leaving place 220Aas a consequence 
of operation "go". Operation "exiting" is also performed by place 220Awhen a process, either an agent or a 

?o place, no longer occupies place 220A as a consequence of the process's destruction. The destruction of a 
process is described in greater detail in Appendix A. The interface of operation "exiting" as defined by class 
"Place" is shown by Figures 23A and 23B. 

As operation "exiting" is performed at the request of engine 132A (Figure 16A), frame 2300 (Figure 23A), 
which records the dynamic state of operation "exiting", is neither part of the execution state of place 220A (Fig- 
ay ure 15A) nor part of the execution state of agent 150A. In fact, at the time at which place 220A is performing 
operation "exiting", agent 150A no longer occupies place 220A. Engine 132A creates a new execution stat 
as part of an "engine process". An engine process is a process created by an engine forthe purpose of carrying 
out a performance of operation "exiting" or of operation "parting". Operation "parting" is discussed below and 
in Appendix A. 

w Figure 23A illustrates frame 2300 immediately prior to performance of operation "exiting". Frame 2300 in- 

cludes stack 2302, which is the current stack. Stack 2302 contains as the arguments of operation "exiting", 
from top to bottom, contact 2308, permit 2306 and ticket 2304. 

Contact 2308 identifies agent 150A (Figure 15A) as the process exiting place 220A. As discussed below 
in greater detail and in Appendix A, a contact has, among its properties, a property "subjectName" and a prop- 
's erty "subject". Property "subjectName" of contact 2308 (Figure 23A) identifies agent 1 50A (Figure 1 5A); prop- 
erty "subject" of contact 2308 (Figure 23A), which is ordinarily a reference to agent 150A(Figure 15A). is voided 
in operation "exiting" so that place 220A is not left with a reference to exiting agent 150A. 

Permit 2306 (Figure 23A) is the current local permit of the process exiting responding place 220A (Figure 
1 5A), i.e. of agent 1 50A. A process's local permit defines the capabilities of the process while occupying a given 
o place. Local permits are discussed in greater detail in Appendix A. Permit 2306 (Figure 23A) is passed "by- 
ProtectedRef" and therefore cannot be altered by place 220A (Figure 15A) in performing operation "exiting". 

The local permit of the exiting process, i. ., permit 2306 (Figure 23A), is used by the ngine interpreting 
responding place 220A (Figure 1 5A) t det rmine the type and amount of resources used by the exiting process 
during occupancy of place 220A so that th authority of the exiting process can be billed for use mad of place 
5 220A and resources contained therein. Th type and amount of resources used are determined by comparison 
between permit 2306 (Figure 23A) and the permit consumed as an argum nt in operation "entering" when 
granting ingress to the exiting process. Operation "entering" is discussed in greater detail above and in Ap- 
pendix A. 
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For example, place 220A (Figure 1 5A) in p rforming operation " ntering a , can store the proposed local per- 
mit, e.g., permit 2206 (Figure 22A), for later comparison with permit 2306 (Figure 23A), which is consumed in 
performance of operation "exiting". As described below and in Appendix A, a contact, e.g., contact 2308, has 
a property "subject Notes". In one embodiment, place 220A stores, within property "subjectNotes" of contact 
2208 (Figure 22A), permit 2206 in performing operation "entering". In performing operation "exiting", place 
220A (Figure 1 5A) determines the amount of resources consumed by agent 1 50A while occupying place 220A 
by comparing permit 2206 (Figure 22A), which is stored within property "subjectNotes" of contact 2208, with 
permit 2308 (Figure 23A), which is consumed in performance of operation "exiting". 

Ticket 2304 (Figure 23A) is passed "byProtectedRefand is equal to ticket 1306 (Figure 13A) which is used 
by agent 150A (Figure 15A) to specify the destination of the trip and informs responding place 220A that agent 
1 50A is leaving responding place 220A as a consequence of performing operation "go". If ticket 2304 (Figure 
23A) is a nil, agent 150A (Figure 15A) is exiting responding place 220A as a consequence of the destruction 
of agent 150 A 

Frame 2300 (Figure 23B) is shown immediately following performance of operation "exiting" by place 220A 
(Figure 1 5A) . Stack 2302 (Figure 23A) is empty as operation "exiting" produces no result As frame 2300 (Fig- 
ure 23B) is not part of the execution state of either place 220A (Figure 1 5A) or agent 1 50A, but is instead part 
of the execution state of an engine process, any exception thrown by performance of operation "exiting" is not 
experienced by, and therefore has no effect upon, either place 220 A or agent 150A. In performing operation 
"exiting", place 220A notes the departure of agent 150 A and objects 140A and 140B, which are owned by agent 
150A. 

Object Interchange 

The time required to transport an agent from one place to another is substantially reduced by limiting trans- 
portation of objects contained by the agent to only those objects that are not likely to have an equivalent object 
at the destination place. Limiting transportation of such objects is particularly important as agent 1 50A, in trav- 
eling from engine 132Ato engine 132Z, includes class objects representing the classes of which agent 150A 
and objects owned by agent 150A are members. As class objects are typically quite large and as the classes 
of which an agent and the objects owned by the agent are members are typically quite numerous, transporting 
all such class objects is impractical. Thus, it is preferred that, in transporting agent 150Afrom engine 132Ato 
engine 1 32B (Figure 1 5A), only class objects representing classes, which are not represented by class objects 
in engine 132B, are transported with agent 150 A to engine 132B. 

Objects, that are likely to have equivalent objects at most places within network 1500 (Figures 15A-15E), 
are members of mix-in class "Interchanged" and therefore include a property "digest". Members of mix-in class 
"Interchanged" are called "interchanged objects". The object which is property "digest" of an interchanged ob- 
ject is alternatively called the digest" of the interchanged object. 

An interchanged object is one that an engine, e.g. engine 132Aor 132B (Figure 15A), deems equivalent 
to any other instance of the interchanged object's class whose digest is equal to the digest of the interchanged 
object. A digest is any object suited to the purpose of distinguishing a first interchanged object from all others. 
For example, a mathematical hash of a canonical binary representation of the interchanged object is suitabl 
for many classes of interchanged objects. Class objects, i.e., objects of class "Class", define built-in classes 
as well as user-defined classes, as described more completely below and in Appendix A, and do not vary from 
engine to engine within computer network 1500. Class objects are therefore interchanged objects. 

The use of digests to reduce the amount of data transferred, and therefore to reduce the time required to 
transport an agent and the objects contained by that agent from one place to another, is illustrated by logic 
flow diagrams 2400 and 2450 (Figures 24A and 24B). 

Logic flow diagram 2400 (Figure 24A) represents the process of transporting agent 1 50A (Figure 1 5A) and 
the objects contained by agent 150Afrom a source engine 132A to a destination engine 132B when inter- 
changed objects are considered. An agent "contains" all objects owned by the agent as well as every class of 
which the agent is a member and every class of which any object owned by the agent is a member. As described 
above, agent 150A and all objects contained by agent 150Aare packaged into a shipping box, encoded and 
transported to engine 132B. In packaging agent 150A and objects contained th rein, source engine 132A col- 
lects all objects contained by agent 150A in step 2402 (Figure 24A). Processing transfers from step 2402 to 
for ach object step 2404 which, with next step 141 2, defines a loop wherein ach object coll ct d in step 2402 
is consid red. Processing transfers from for each object step 2404 to digest test step 2406 in which the class 
membership of each object contained by agent 1 50A is checked to det rmine whether each object has a digest 

As discussed above and in greater detail in App ndices A and E, members of mix-in class "Interchanged" 
can include a digest Therefore, if an object has a digest, the object is an interchanged bj ct If an interchanged 
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object does not have a digest, i.e., if attribute "digest" of the interchanged object is a nil, th interchanged obj ct 
is not interchanged but is instead treat d as a non-interchanged object. 

If an bject has no digest, even if the object is an interchanged object, processing transfers from digest 
test step 2406 to step 2410 in which the object is encoded according to the encoding rules of Appendix B and 
5 included in the shipping box. Otherwise, if the object has a digest, processing transfers from digest test st p 
2406 to step 2408 in which the digest of the object and a citation of the class of which the object is an instance 
are encoded according to the encoding rules of Appendix B and included in a parts box which is in turn included 
in the shipping box. 

Processing transfers from step 2408 or step 2410 to next step 2412 in which processing is transferred t 
10 for each object step 2404. Engine 1 32A repeats the process of steps 2406, 2408 and 241 0 for each object con- 
tained by agent 150A in a loop defined by for each object step 2404 and next 241Z If all objects collected in 
step 2402 have been processed according to the loop of for each object step 2404 and next object step 2412, 
processing transfers from for each object step 2404 to a transfer out encoded agent step 2414. 

In transfer out encoded agent step 2414, the shipping box is encoded and is transported by source engin 
15 1 32A to destination engine 1 32B, as described above. Thus, the encoded agent which is transported to des- 
tination engine 132B includes all objects contained by the agent which have no digests and the digests of all 
objects contained by the agent which are interchangeable and which have digests. Transfer out encode agent 
step 2414 is represented in double boxes to indicate interaction between engines across the network. Such 
an exchange of binary data between engines is discussed above and in Appendices C and F. 
20 Logic flow diagram 2450 (Figure 24B), illustrates the transfer of encoded agent 1 50Af rom the perspectiv 

of destination engine 132B. Destination engine 132B receives the encoded agent as binary data from source 
engine 132A in transfer in encoded agent step 2452. As described above in the context of Figures 15A-15E, 
the encoded agent can pass through one or more intermediate engines, e.g., engine 1 32Z, enroute from engin ' 
132A to engine 132B. 

25 Processing transfers from transfer in encoded agent step 2452 to step 2454 in which the encoded agent 

is decoded, thereby reconstructing the shipping box whose contents are the agent objects contained by the 
agent Each of the objects, which do not have digests and which are contained by the agent, and the digests 
of the interchanged objects contained by the agent which have digests, are processed by destination engin 
1 32B according to the loop formed by for each object step 2456 and next step 2462. Each iteration of the loop 

30 processes one of the objects decoded in step 2454. 

Processing transfers from for each object step 2454 to digest test step 2464. In digest test step 2464, des- 
tination engine 1 32B determines whether an object is a digest. If the object is not a digest, processing transfers 
from digest test step 2464 directly to next object step 2462. Conversely, if the object is a digest, processing 
transfers from digest test step 2464 to test step 2466 and the object is called "the subject digest". In test step 

35 2466, destination engine 132B determines whether the subject digest is equivalent to a digest of an inter- 
changed object which is present in engine 132B. The method by which such a determination is made is dis- 
cussed in more detail below. 

If an interchanged object having an equivalent digest is found in step 2466, processing transfers from test 
step 2466 to substitute step 2468. In substitute step 2468, the interchanged object is substituted for the subject 

<o digest by replacing all references within the objects decoded in step 2454 to the interchanged object repre- 
sented by the subject digest with references to the found interchanged object. Processing transfers from sub- 
stitute step 2468 to next object step 2462. 

If, on the other hand, no interchanged object having an equivalent digest is found in test step 2466, proc- 
essing transfers from test step 2466 to step 2470. In step 2470, the subject digest is added to a list of digests. 

*5 A new list is created if no such list exists. Processing transfers from step 2470 to next step 2462. 

From next step 2462, processing transfers to for each object step 2456. If all objects decoded in step 2454 
have been processed according to the loop of for each object step 2456 and next step 2462, processing trans- 
fers from for each object step 2456 to a list test step 2476, which is described below. 

An engine searches for equivalent interchangeable objects in step 2466 as follows. Each engine contains 

so one or more places which can exchange equivalent interchangeable objects. Each such place includes a "re- 
pository" of interchangeable objects which are present within the place. Dictionary 2490 (Figure 24D) is th 
repository of place 220B (Figure 15D). The keys of dictionary 2490 (Figure 24D) are classes, i.e., classes 
2490K1, 2490K2, 2490K3 and 2490K4. Associated with each class is a dictionary; for example, associated 
with classes 2490K1-2490K4 are dictionaries 2490A, 2490B, 2490C and 2490D, respectively. 

5 Each of dictionaries 2490A-2490D have the same general rganization; dictionary 2490A is illustrative. 

The keys of dictionary 2490Aare digests, i.e., digests 2490AK1 , 2490AK2 and 2490AK3. Associated with each 
digest is an interchanged object whose digest is the associated digest; for xample, associated with digests 
2490AK1-2490AK3 are interchanged bjects 2490AV1, 2490AV2 and 2490AV3, respectiv ly. 
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An interchanged object is retrieved from dictionary 2490 in two st ps. As discussed above, both a digest 
and a citation of a class are used within a parts box to represent an interchanged bject. In the first step, a 
citation is used to retrieve the dictionary of dictionaries 2490A-2490D which is associated with the class r f- 
erenced by the citation. For example, if the citation references class 2490K1 f dictionary 2490A is retrieved. 

5 In the second step, the retrieved dictionary is searched for an association between a digest equivalent t 

the digest which is included in the parts box and an interchanged object. If an association is found, the inter- 
changed object is retrieved. If no association is found, the place contains no interchanged object which is equiv- 
alent to the interchanged object represented by the citation and digest in the parts box. Thus, a repository such 
as dictionary 2490 (Figure 24D) is used to determine whether a place contains an equivalent interchanged ob- 

10 ject and to retrieve such an object 

As described above, processing transfers from for each object step 2456 to list test step 2476. In list test 
step 2476, the destination engine, e.g. engine 132B, determines whether a list of digests was created in step 
2470 and, if so, whether the list is empty. If the list of digests does not exist or is empty, processing transfers 
from list test step 2476 to activate traveling agent step 2478 in which engine 132B activates traveling agent 

15 1 50A by scheduling agent 1 50A for execution. Processing transfers from activate traveling agent step 2478 
to terminal step 2479 in which the transfer of agent 150A, as carried out by engine 132B, completes success- 
fully. 

If, on the other hand, a list was created in step 2470 and the list contains at least one digest, an equivalent 
object for at least one interchanged object is not found within destination engine 1 32B and processing transfers 

20 from list test step 2476 to hold traveling agent step 2471. In hold traveling agent step 2471, traveling agent 
1 50A is held in a suspended state in a holding queue within engine 132B. Processing transfers from hold trav- 
eling agent step 2471 to step 2472. 

In step 2472, the destination engine, e.g. engine 132B, creates an object retrieval agent, i.e., an "ORA". 
The ORA retrieves interchanged objects from the source engine, e.g., engine 132A according to logic flow dh- 

25 agram 2480 (Figure 24C). Processing transfers from step 2472 to step 2474 in which the ORA is directed to 
perform operation live", thereby initiating interpretation of the ORA. As discussed below in greater detail, th 
central activity of the ORA is shown by logic flow diagram 2480 (Figure 24C). Processing transfers from step * 
2474 to terminal step 2479 in which the transfer of agent 1 50A, as carried out by engine 1 32B, completes suc- 
cessfully. It should be noted that traveling agent 150A is not activated and is in the form of a shipping box. 

30 Agent 150A is reconstituted from the shipping box and reactivated by the ORA as described below. 

Logic flow diagram 2480 (Figure 24C) illustrates the central procedure of the ORA. In step 2482, the ORA 
travels to the source engine, e.g., engine 132A, by performance of operation "go". Processing transfers from 
2482 to step 2484 in which the ORA collects from an interchanged object repository, such as dictionary 2490 
(Figure 24D), within engine 1 32A a copy of each object having a digest that is equivalent to a digest contained 

35 in the list of digests. Processing transfers from step 2484 to step 2485. 

In step 2485, the ORA travels back to the destination engine, e.g., engine 132B, by performance of oper- 
ation "go". The ORA carries to the destination engine copies of those objects whose digests are contained in 
the list of digests, namely, those objects for which there are no equivalent objects within the destination engine. 
Processing transfers from step 2485 to step 2486. In step 2486, the ORA substitutes the objects collected for 

40 the digests within agent 150A as described above. Processing transfers from step 2486 to activate traveling 
agent step 2487, in which agent 1 50A is reconstituted from the shipping box and activated as described above. 
The reconstitution of an agent and the objects contained by the agent from a shipping box is described in great- 
er detail in Appendix D. Processing transfers from step 2487 to terminal step 2488 in which the central proce- 
dure of the ORA is successfully completed. 

45 Thus, efficiency is achieved by transporting across network communications media only those inter- 

changed objects which are not equivalent to interchanged objects within the destination engine. 

Operation "Send" 

so An agent is capable of traveling to several places simultaneously by performing operation "send". Figure 

25 shows the state of network 2500 prior to performance of operation "send" by agent 150A. In the example 
of Figure 25, agent 1 50A in data portion 1 32A-D of engin 1 32A is configured to transport a don of itself to 
place 220B in data portion 132B-D of engine 132B and a clone of itself to plac 220C in data portion 132C-D 
of engine 132C simultaneously. In other words, agent 150A is performing operation "send", supplying as the 

55 argument to operation "send" a list of two tickets specifying places 220B and 220C as destination places for 
clones of agent 1 50 A. A done of agent 1 50A is a c py of agent 1 50A which is made by replicating agent 1 50A, 
including th execution state of agent 150A, to f rm the copy and which is mad "active" by assigning a new 
name and identif i r to the copy and scheduling the copy for execution by an engine. Clones are described in 
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greater detail in Appendix A. 

Th interface of operation "send" is illustrated by Figures 26A, 26B and 26C. Figure 26A illustrates frame 
2602, which records the dynamic state of peration "send" as performed by agent 150A and which is a part of 
the execution state of agent 150A, immediately prior to performance of operation "send". The execution stat 
of a process, including an agent is described in greater detail below and in Appendices A and B. 

Included in frame 2602 is stack 2604. Stack 2604 is the stack from which arguments are popped and to 
which a result is pushed during performance of operation "send". Stack 2604 is therefore the "current stack" 
in the context of operation "send". The "current stack" is defined and explained more completely below and in 
Appendices A and B. 

At the top of stack 2604, as indicated by letter T", is list 2606 whose items are tickets 2608 and 2610. 
Tickets 2608 and 261 0 of list 2606 each define a trip to be taken by a corresponding clone of agent 15 OA 

Objects 2618 and 2620 are property "travelNotes" of tickets 2608 and 2610, respectively. Objects 2618 
and 2620 provide a mechanism by which respective clones created by performance of operation "send" can 
be distinguished. For example, in forming tickets 2608 and 2610, agent 150A can store within objects 2618 
and 2620 strings whose respective texts are "Able" and "Baker". In such a case, the clone of agent 150A cor- 
responding to ticket 2608 retrieves the string "Able" from property "travelNotes" of ticket 2608. Similarly, th 
clone of agent 1 50A corresponding to ticket 261 0 retrieves the string "Baker" from property "travelNotes" of 
ticket 2610. 

The particular implementation by which the respective clones are distinguished is ultimately up to the user 
of the present invention. The following is another example. Stored within object 261 8 is an integer whose value 
is one, thereby representing the position of corresponding ticket 2608 within list 2606. Similarly, stored within 
object 2620 is an integer whose value Is two, thereby representing the position of corresponding ticket 2610 
within list 2606. 

Permits 2622 and 2624 are properties "destinationPermit" of tickets 2608 and 2610, respectively. Integers 
2626 and 2628 are properties "charges" of permits 2622 and 2624, respectively. 

Permit 2612 is property "permit" of agent 150Aand therefore represents a part of the internal state of agent 
150A. As described above and in Appendix A, permit 2612 limits the execution of agent 150A. Boolean 2614 
is property "canSend" of permit 2612. If the value of boolean 2614 is "false", operation "send" fails and throws 
an exception of class "Permit Violated". Property "charges" of permit 2612 is integer 2616. As discussed in 
greater detail in Appendix A, integer 2616 represents the processing allowance of agent 150A. 

In the example of Figure 25, agent 1 50A, whose current location is place 220A, is configured to transport 
respective clones of agent 150Ato places 220B and 220C. As agent 150A sends a clone of itself to each des- 
tination place defined by a ticket in list 2606 (Figure 26A), performance of operation "send" eventually creates 
as many clones of agent 150A as there are tickets in list 2606. Figures 27A and 27B illustrate a simple em- 
bodiment of operation "send" wherein engine 132A (Figure 27A) creates within data portion 132A-D a number 
of clones of agent 1 50A equal to the number of tickets in list 2606 (Figure 26A). In this example, list 2606 (Figure 
26A) contains two tickets, i.e., tickets 2608 and 261 0. Therefore, engine 1 32A creates two clones, agent 1 50A- 
1 and agent 150A-2, of agent 150A (Figure 27B). Amore efficient embodiment, in which cloning of the respond- 
ing agent is deferred, is described below. 

In forming the clones of agent 150A, permits 2622 and 2624 are made property "permit" of the clones cre- 
ated. In other words, permit 2622 is property "permit" of agent 1 50A-1 and permit 2624 is property "permit" of 
agent 1 50A-2. In creating agents 1 50A-1 and 1 50A-2, the allowances of permits 2622 and 2624 are subtracted 
from the corresponding allowances of permit 2612 of agent 150A, i.e., the agent that is being cloned. In other 
words, the value of integers 2626 and 2628 are subtracted from integer 261 6, which is the charges allowance 
of agent 150A, i.e., property "charges" of the permit of agent 1 50 A upon creation of agents 150A-1 and 150A- 
2. If integer 261 6 is not greater than or equal to the sum of integers 2626 and 2628, operation "send" fails and 
throws an exception of class "Permit Violated" since the charges allowance of agent 1 50A is less than the sum 
of the charges allowances of the clones created from agent 150A. 

Thus, the permits which are part of the tickets supplied as arguments to operation "send" form the native 
permits of the clones created in performance of operation "send". As tickets 2608 and 2610 define trips to be 
taken by respective clones of agent 150A, permits 2622 and 2624 are property "permit" of tickets 2608 and 
2610, respective, and are therefore also the local permits of resp ctive clones of responding agent 160A. 

In a s cond mbodiment of the present invention, operation "send" consumes, as an argument in addition 
to list 2606, an int g r (not shown). In creating clones of responding agent 150 A respective native permits 
are form d as described above with th exception that property "charges" of each native permit is initially equal 
to the integer consumed. 

A third embodiment of the present inv ntion is thesam as the second embodiment described above with 
the exception that a list of integers is consumed in lieu of a single integer. Additionally, property "charges" of 
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ach native permit, which is derived from property "permit" of a ticket within list 2606 (Figure 26A), is initially 
qua) to the integer at a position within the consumed list of integers that is equal to the position within list 
2606 of the ticket from which the native permit is derived. For example, property "charges" of the native permit 
of the clone corresponding to ticket 2608 at position one within list 2606 is initially equal to the integer at position 
5 one in the consumed list of integers (not shown). Similarly, property "charges" of the native permit of the done 
corresponding to ticket 2610 at position two within list 2606 is initially equal to the integer at position two in 
the consumed list of integers. 

In a fourth embodiment of the present invention, operation "send" consumes, as an argument in addition 
to list 2606, a permit (not shown). In creating clones of responding agent 150A, each respective native permit 
10 is a copy of the consumed permit. 

A fifth embodiment of the present invention is the same as the fourth embodiment described above with 
the exception that a list of permits is consumed in lieu of a single permit. Additionally, each native permit of a 
respective clone corresponding to a ticket within list 2606 (Figure 26A) is initially equal to the permit ata position 
within the consumed list of permits that is equal to the position within list 2606 of the ticket to which the clone 
is corresponds. For example, the native permit of the clone corresponding to ticket 2608 at position one within 
list 2606 is initially equal to the permit at position one in the consumed list of permits (not shown). Similarly, 
the native permit of the clone corresponding to ticket 2610 at position two within list 2606 is initially equal to 
the permit at position two in the consumed list of permits. 

In each of the described embodiments, property "charges" of permit 2612, which is the permit of respond- 
20 ing agent 150 A, is reduced by the total of respective properties "charges" of the native permits of the clones 
of agent 150A created in performance of operation "send". 

Each clone of agent 150A is transported to a place identified by the corresponding ticket as a destination 
place. For example, ticket 2608 identifies place 220B as the destination for agent 1 50A-1 , and ticket 261 0 iden- 
tifies place 220C as the destination for agent 150A-2. Each clone travels to its respective destination place 
25 through the cooperation of the source engine 132Awith a corresponding destination engine, e.g., either engin 
132B or engine 132C. The transportation of an agent clone, e.g. either agent 150A-1 or agent 150A-2, from 
one place to another in performing operation "send" is as described above in detail in conjunction with operation 

"go". 

If, in performance of operation "send", agent 150A successfully creates agents 150A-1 and 150A-2, per- 

30 formance of operation "send" by agent 1 50A succeeds even if the transportation of any or all of the agent clones 
fails. If a trip of an agent clone fails, the trip exception is thrown by the agent clone, not the agent which originally 
performed operation "send". 

A portion of the execution state of agent 150A immediately following performance of operation "send" by 
agent 150A is shown in Figure 26B. Stack 2604, which is the current stack as described above, contains a nil 

35 object 2630. A nil object is produced as a result for the original agent, thereby distinguishing the original agent 
from agent clones created in performance of operation "send". 

Figure 26C shows a portion of the execution state of agent 150A-1 after performance of operation "send" 
by agent 150A. The execution state of agent 150A-2 after performance of operation "send" by agent 150A is 
directly analogous to the execution state of agent 150A-1 as described immediately below. 

40 Permit 2622 is property "permit" of agent 150A-1. Stack 2604-1 is a copy of stack 2604 produced in the 

creation of agent 1 50A-1 . Stack 2604-1 is the current stack of agent 1 50A-1 . At the top of stack 2604- 1 is ticket 
stub 2632. Ticket stub 2632 is the result produced by operation "send" for an agent clone created by perfor- 
mance of operation "send". Ticket stub 2632 is derived from ticket 2608. 

Ticket stub 2632 is a member of a class "Ticket Stub". Ticket stub 2632 has, among other properties, prop- 

45 erties "way" and "travelNotes". Ticket 2608 is a member of a class "Ticket". Class "Ticket" is a subclass of class 
Ticket Stub"; therefore, ticket 2608 has, among other properties, properties "way" and "travelNotes", defini- 
tions of which are inherited from superclass Ticket Stub". Ticket stub 2632 is derived from ticket 2608 such 
that properties "way" and "travelNotes" of ticket stub 2632 are equal to properties "way" and "travelNotes", 
respectively, of ticket 2608. As discussed above, property "travelNotes" of ticket 2608 (Figure 26A) can be used 

so to distinguish agent 1 50A-1 from agent 1 50A-2. Similarly, the current stack (not shown) of agent 1 50A-2 con- 
tains a ticket stub (not shown) whose property "travel Notes" is object 2620. 

Figure 28 shows computer network 2500 after operati n "send" has been performed by ag nt 1 50A. Agent 
150A remains in data porti n 132A-D of computer process engine 132A. Agent 150A-1 occupies place 220B 
in data portion 132B-D of engine 132B. Similarly, agent 150A-2 occupies place 220C executing in data portion 

55 132C-D of engine 132C. 

The access of operation "send" is "private" permitting only the responder to request the operation. As dis- 
cussed in greater detail below and in Appendix A, each feature of the present invention has an access which 
specifies under what conditions the feature can be requested. As th access of op ration "send" is private, 
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only agent 150Acan initiate performance of operation "send" by agent 150A. Even engin 132A cannot initiat 
performance of operation "send" by agent 1 50A. 

Deferred Cloning 

Substantial savings in the amount of time required to perform operation "send" and in space occupied by 
clones of an agent created during performance of operation "send" are realized by "deferred cloning'. Deferred 
cloning occurs when the engine carrying out performance of operation "send" determines that two or more 
clones of the same agent are to be transferred to a single destination engine. In such a case, a single clone 
is transferred to the destination engine and additional clones are derived from the single clone at the destin- 
ation engine. Figures 29A-29D are illustrative. 

Agent 150A (Figure 29A) occupies place 220A in engine 132A. Engine 132A is a computer process exe- 
cuting within computer system 110A (not shown). Agent 150A is performing operation "send", supplying as the 
argument to the operation a list of three tickets (not shown) specifying places 220B, 220C and 220D as des- 
tination places for clones of agent 150A. Engine 132A is in communication with engine 132E across commu- 
nications link 1 02AE. Communications link 1 02AE is as described above with respect to communications link 
102AZ (Figure 15A) in conjunction with operation -go". In addition to engine 132A, engine 132E is in commu- 
nication with engines 132Band 132F across communications link 102EBF. Additionally, engine 132F is in com- 
munication with engines 132C and 132D across communications link 102FCD. Places 220B, 220C and 220D 
are processes interpreted by engines 132B, 132C and 132D, respectively. Thus, for clones of agent 150Ato 
reach places 220B, 220C and 220D, each clone must first be transferred to engine 132E. 

Created within engine 132A is a single clone, i.e., agent 150A-1, of agent 150A. The execution state of 
agent 1 50A-1 includes a send frame 2902 as agent 1 50A-1 is performing operation "send". The execution state 
of an agent is discussed in greater detail below and in Appendix A. Send frames are discussed in greater detail 
in Appendix B. Send frame 2902 (Figure 30A) includes list of tickets 2904 which includes tickets 2904B, 2904C 
and 2904D which in turn specify places 220B, 220C and 220D, respectively, as destination places. Agent 
1 50A-1 (Figure 29A), the single clone of agent 150A, therefore represents three separate agent clones which 
are to travel to places 220B, 220C and 220D, respectively. 

Encoded agent 150A-1-E (Figure 30B) is the result of encoding agent 150A-1 (Figure 29A) according to 
the encoding rules of Appendix B. Included in encoded agent 150A-1-E (Figure 30B) are destinations 150A- 
1-E-D1, 150A-1-E-D2, and 150A-1-E-D3 which define respective transfer destinations of the three clones of 
agent 1 50A (Figure 29A). As all three clones of agent 1 50A are transferred to engine 1 32E, destinations 1 50A- 
1-E-D1, 150A-1-E-D2, and 150A-1-E-D3 (Figure 30B) all define engine 132E as the transfer destination of a 
respective clone of agent 150A (Figure 29A). Engine 132A determines that destinations 150A-1-E-D1, 150A- 
1-E-D2, and 150A-1-E-D3 (Figure 30B) each define engine 132E as a transfer destination and transfer^ a sin- 
gle clone of agent 150A (Figure 29A), i.e., encoded agent 150A-1-E (Figure 30B) to engine 1 32E (Figure 29B). 
Thus, rather than transporting three separate clones from engine 132A to engine 132E f a single clone is trans- 
ported to engine 1 32E reducing proportionally the amount of space within engine 1 32A occupied by clones of 
agent 150A and the amount of time required to transport clones to engine 132E. 

Agent 1 50A-1 is encoded and transferred to engine 1 32E (Figure 29B) as discussed above in conjunction 
with operation "go". Engine 132E retrieves list 2904 of send frame 2902 of agent 150A-1. As the structure of 
an encoded agent is standardized as described in Appendix B, an engine, e.g., engine 132E, can retrieve list 
2904 without decoding encoded agent 1 50A-1 . Engine 1 32E determines that one clone corresponding to ticket 
2904B of send frame 2902 is to be transported to engine 132B and that two clones corresponding to tickets 
2904C and 2904D are to be transported through engine 132F to engines 132C and 132D, respectively. There- 
fore, a second clone, agent 1 50A-2 (Figure 29C), is created from agent 1 50A-1 by engine 1 32E. As agent 1 50A- 
1 is encoded, agent 150A-2, which is a copy of agent 150A-1, is encoded as well. Agent 150A-2 includes send 
frame 2902-2, and send frame 2902-2 in turn includes list of tickets 2904-2. List of tickets 2904-2 includes a 
single ticket 2904B which is removed from list of tickets 2904 of send frame 2902 of agent 150A-1. 

Agent 1 50A-2 is transferred to engine 1 32B, and agent 1 50A-1 is transferred to engine 1 32F (Figure 29D) 
As ticket 2904B specifies place 220B as the destination of a trip and ticket 2904B is the only ticket in send 
frame 2902-2, place 220B is the destination of agent 1 50A-2 and no further clones of agent 1 50A are created 
from agent 150A-2. Agent 150Ar2 is decoded by ngine 132B. Agent 150A-2 is granted occupancy to place 
220B by performance of operation "entering" by place 220B as described above, and p rformance of operation 
55 -send" for agent 150A-2 is completed. S nd frame 2902B is therefore removed from the execution state f 
agent 150A-2 as discussed below in the context of the execution model. 

Agent 150A-1 is transferred to engin 132F. Included in send frame 2902, which is part of th execution 
state of agent 1 50A-1 , is list of tick ts 2904 which in turn includes tickets 2904C and 2904D. Thus, agent 1 50A- 
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1 repres nts two clones of agent 1 50A which are traveling to places 220C and 220D, resp ctively. Therefore, 
by transferring a single clone, i.e. agent 150A-1, from engine 132E to engine 132F, substantial savings are 
realized in storage space in engine 132E and in time required to transport data betwe n engine 132E and n- 
gine 132F as described above. 

5 In the manner described above, in engine 132F (i) a third clone of agent 1 50A, i.e., agent 150A-3, is formed 

from agent 150A-1, and (ii) a send frame (not shown) is included in agent 150A-3 which includes ticket 2904C. 
As agent 150A-1, from which agent 150A-3 is copied, is encoded, agent 150A-3 is encoded as well. Ticket 
2904C is removed from send frame 2902 of agent 150A-1. Agent 150A-3 is transferred to engine 132C, and 
agent 150A-1 is transferred to engine 132D (Figure 29E). 

10 Engine 1 32C includes place 220C which is the trip destination of agent 1 50A-3 as defined by ticket 2904C, 

and engine 1 32D includes place 220D which is the trip destination of agent 1 50A-1 as defined by ticket 2904D. 
In the manner described above, (i) engine 1 32C decodes agent 1 50A-3 and agent 1 50A-3 is granted occupancy 
of place 220C by performance of operation "entering 0 and (ii) engine 132D decodes agent 150A-1 and agent 
1 50A-1 is granted occupancy of place 220D by performance of operation "entering". Since send frame 2902 

15 (not shown) contains only a single ticket which specifies place 220D as the destination, operation "send" com- 
pletes for agent 150A-1. Similarly, as agent 150A-3 includes a send frame specifying a single place, namely, 
place 220C which is the place occupied by agent 150A-3, as the destination of a trip, operation "send" com- 
pletes for agent 150A-3 as well. 

Each of agents 150A-1, 150A-2 and 150A-3 completes performance of operation "send" having an exe- 

20 cution state which includes a send frame which includes a single ticket which defines the trip taken by the re- 
spective agent clone. The respective single ticket is used as described above to derive a ticket stub which is 
produced as the result of the respective agent's performance of operation "send". 

Thus, substantial amounts of computer storage space and time are saved in performance of operation 
"send" by deferring cloning as long as possible in the transportation of the several clones to respective des- 

25 ti nation places. 

The structure of send frame 2902 during transport of agent 150A-1 is shown in Figure 30. Class "Send 
Frame" defines property "tickets". Property "tickets" of send frame 2902 is list 2904 whose items are tickets 
2904B, 2904C and 2904D. Tickets 2904B, 2904C and 2904D define respective trips to be taken by respective 
clones of responding agent 150A. 

30 As discussed above, performance of operation "send" by agent 1 50A creates one or more agent clones, " 

each agent clone representing one or more clones of agent 150A. If forming each agent clone, e.g. agent 150A- 
1 (Figure 29A), a copy of send frame 2902 is included in the agent clone. Property "tickets" of the send frame 
copy is modified so as to include only those tickets corresponding to the clones represented by the agent clone. 
For example, agent 150A-2 (Figure 29C) includes send frame 2902-2 which in turn includes ticket 2904B and 

35 agent 150A-1 includes send frame 2902 which in turn includes tickets 2904C and 2904D. Therefore, agent 
1 50A-2 represents a single clone of agent 150A which is traveling to the place specified by ticket 2904B, name- 
ly, place 220B. Similarly, agent 150A-1 represents two clones of agent 150A which are traveling to places spe- 
cified by tickets 2904C and 2904D, namely, places 220C and 220D, respectively. 

Once each clone has reached its respective destination, property "tickets" of send frame 2902 (Figure 

40 30) is a list of exactly one ticket. For example, agents 1 50A- 1 , 1 50A-2 and 1 50A-3 (Figure 29E) include send 
frames 2902, 2902-2 and 2902-3, respectively, which each include a single ticket, namely, respective tickets 
2904D, 2904B and 2904C. Thus, each send frame contains the single ticket defining the trip taken by the cor- 
responding agent clone. The single ticket is used as described above to form a ticket stub which is produced 
as a result by performance of operation "send" by each respective agent clone. 

45 Thus, substantial savings are realized in computer storage space and data transportation time by deferring 

cloning of an agent performing operation "send" as long as two or more agent clones are taking trips which 
are coextensive in part. As described above in the context of operation "go", if an exception is thrown during 
performance of operation "go" by an agent, the agent can be placed in purgatory. Similarly, if an exception is 
thrown during performance of operation "send" by an agent clone, the agent clone can be placed in purgatory. 

so Additionally, if transportation of multiple clones of an agent which are represented by a single encoded agent, 
e.g. agent 150A-1 (Figure 29B), fails, each clone represented by the encoded agent is decoded, activated, and 
placed in purgatory as describ d above. 

I nteraction Between Agents: Operation "Meet" 

55 

Two agents, which ccupy the same place, are capable of interacting with one another by one agent re- 
questing that the ther perform an operation, or set or query an attribute. Information is exchanged between 
the two agents through the arguments and result of the operation requested or through the attribute which is 
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setorqu ried. For example, agent 150A and 1 SOB occupy place 220B which is executing within engine 132B 
(Figure 15E). Therefore, agent 150Aand agent 150B are capable of interacting by (i) agent 150A requesting 
that agent 150B perform a feature or by (ii) agent 150B requesting that ag nt 150A perform a feature. 

Agent 150A is capable of requesting that agent 150B perform a feature only if agent 150A contains a ref- 
5 erence to agent 1 SOB. Similarly, agent 1 SOB is capable of requesting that agent 1 50A perform a feature only 
if agent 150B contains a reference to agent 150A. Agent 150A obtains a reference to agent 150B by requesting 
performance of operation "meet" by a meeting place of which agents 150A and 1 SOB are occupants. To this 
point, place 220B has only been described as a place occupied by agents 150A and 150B. For purposes of 
the following discussion, place 220B is a meeting place, i.e., a member of class "Meeting Place 0 . Meeting places 
10 are discussed in more detail in Appendix A. 

Figures 31 A and 31 B illustrate the interface of operation "meet 0 . Frame 3100 is part of the execution state 
of agent 150A. Frame 3100 records the state of the performance of operation "meet" by meeting place 220B. 
Meeting place 220B is identified within the execution state of agent 150Aas the responder of operation "meet". 

Frame 3100 includes stack 3102, which is the current stack. Immediately prior to performance of operation 
is "meet" (Figure 31A), stack 3102 contains, at its top, petition 3106. Petition 3106 is an argument consumed by 
performance of operation "meet". Petitions, i.e. members of class "Petition", are discussed more completely 
below and in Appendix A. 

Logic flow diagram 3200 (Figure 32) shows the implementation of operation "meet" as performed by meet- 
ing place 220B. Engine 132B (Figure 15E), in carrying out operation "meet" as performed by meeting place 

20 220B, determines the petitioned agent by parsing petition 3106 (Figure 31A). Petition 3106 specifies a peti- 
tioned agent by name, by class or by both. A petitioned agent is an agent specified by a petition as the agent 
with which an agent requesting a meeting is configured to meet. 

Engine 132B pops petition 3106 from the current stack in a pop petition step 3202 (Figure 32). Processing 
transfers from pop petition step 3202 to a step 3204. In step 3204, engine 132B creates a new, empty list of 

25 telenames. The telenames of the list created in step 3204 are telenames of petitioned agents which have re- 
jected a meeting with the requesting agent. The list is initially empty as initially no petitioned agent has rejected 
a meeting with the requesting agent. 

Processing transfers from step 3204 to a find petitioned agent step 3206 in which the engine carrying out 
performance of operation "meet", e.g., engine 132B (Figure 15E), finds a petitioned agent, i.e., an agent which 

30 satisfies petition 31 06 (Figure 31 A), whose telename is not an item of the list of telenames created in step 3204 
(Figure 32). An agent satisfies petition 3106 (Figure 31 A) as follows. 

As described in greater detail in Appendix A, petition 31 06 includes a property "agentName" and a property 
"agentaass" (neither shown). Both properties "agentName" and "agentClass" are optional and can therefore 
each be a nil. If property "agentName" of petition 31 06 is a telename and property "agentClass" is nil, a peti- 

w tioned agent is an agent whose telename is specified by the telename that is property "agentName" of petition 
31 06. If property "agentClass" is a citation and property "agentName" is nil, a petitioned agent is an agent which 
is a member of a class specified by the citation that is property "agentClass" of petition 31 06. If neither property 
is nil, a petitioned agent is an agent which satisfies both criteria. If both properties are nil, an exception of class 
"Meeting Invalid" is thrown, causing operation "meet" to fail. 

w Processing transfers from find petitioned agent step 3206 to test step 3208 in which engine 132B deter- 

mines whether a petitioned agent is found in find petition agent step 3206. If no petitioned agent is found in 
find petitioned agent step 3206, processing transfers from test step 3208 to a wait step 3222 which is described 
below. Conversely, if a petitioned agent is found in find petitioned agent step 3206, processing transfers from 
test step 3208 to a meeting step 3210. 

« In meeting step 3210, the petitioned agent is requested to perform operation "meeting" by engine 132B 

which is interpreting meeting place 220B. In performing operation "meeting", the petitioned agent agrees or 
refuses to participate in a meeting with agent 150A. Operation "meeting" is discussed further below and in 
Appendix A. 

After performance of operation "meeting" by the petitioned agent, processing transfers from meeting step 
» 321 0 to test step 321 2. In test step 32 1 2, engine 1 32B determines whether operation "meeting" completed suc- 
cessfully, indicating that the petitioned agent agrees to the meeting. Ifthe petitioned agent refuses the meeting, 
i.e., processing transfers from test step 3212 to a first fully qualified test step 3234, which is described bel w! 
C nversely, if th petitioned agent agre stoth meeting, i.e., if op ration "meeting" completed successfully, 
processing transfers from test step 3212 to a build contact step 3216. 
5 In build contact step 3216, a contact 31 08 (Figure 31B), whose subject is the petitioned agent, is created. 

Processing transfers from build contact step 3216 (Figure 32) to a push contact step 3218 in which contact 
31 08 (Figure 31 B) is pushed on to stack 31 02, thereby producing contact 31 08 as a result Processing transfers 
from push contact step 3218 to terminal step 3220 in which operation "meet" completes successfully. 
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However, as discussed above, if th petitioned agent throws an xception in performance of operation 
"meeting", thereby refusing to meet with agent 150A, processing transfers from test step 3212 to first fully 
qualified test step 3234. In first fully qualified test step 3234, engine 1 32B det rmines whether petition 31 06 
(Figure 31 A) is fully qualified. Petition 3106 is fully qualified if the telename that is property "agentName" of 

5 petition 3106 is fully qualified. A telename includes both a property "authority" and a property "identity". Tel- 
enames are described more completely in Appendix A. Property "identity" of a telename is optional, i.e., can 
be a nil. If property "identity" of a telename is nil, the telename is partially qualified and denotes all named 
objects of the authority that is property "authority" of the telename. On the other hand, if property "identity" 
of a telename is not nil, the telename is fully qualified and denotes exactly zero or one named object. 

10 In first fully qualified test step 3234 (Figure 32), engine 132B determines whether petition 3106 (Figure 

31 A) is fully qualified. If petition 31 06 (Figure 31 A) is fully qualified, processing transfers from first fully quali- 
fied test step 3234 to terminal step 3236 in which an exception of class "Meeting Denied" is thrown, causing 
operation "meet" to fail. Thus, if petition 31 06 (Figure 31 A) is fully qualified and the one agent which satisfies 
petition 3106 rejects the meeting, operation "meet" fails. On the other hand, if petition 3106 is not fully qualified, 

15 processing transfers from first fully qualified test step 3234 to an add agent to list step 3214. 

In add agent to list step 3214, the petitioned agent found in find petitioned agent step 3206 is added to 
the list of telenames created in step 3204. Processing transfers from add agent to list step 3214 to find peti- 
tioned agent step 3206. 

As discussed above, if no petitioned agent is found in find petitioned agent step 3206, processing transfers 
20 from test step 3208 to wait step 3222. In wait step 3222, interpretation of agent 1 50A is suspended until petition 
3106 (Figure 31 A) expires or until an agent enters meeting place 220B, i.e., until meeting place 220B success- 
fully performs operation "entering". As described more completely in Appendix A, petition 31 06 includes a prop- 
erty "maximumWait" which defines a maximum amount of time that can elapse from the start of performance 
of operation "meet" before operation "meet" must conclude, either successfully or otherwise. Petition 3106 ex- 
25 pires when the amount of time specified in property "maximumWait" has passed since the start of performance 
of operation "wait". 

When petition 3106 expires or when an agent enters meeting place 220B, interpretation of agent 150A re- 
sumes and processing transfers from wait step 3222 (Figure 32) to a timeout test step 3224. In timeout test 
step 3224, engine 132B (Figure 15E) determines whether resumption of interpretation of agent 150A (Figure 
30 31 A) results from expiration of petition 3106. If interpretation of agent 150A is resumed as a result of the ex- 
piration of petition 3106 (Figure 31 A), processing transfers from timeout test step 3224 (Figure 32) to terminal 
step 3226 in which an exception of class "Petition Expired" is thrown, causing operation "meet" to fail. 

On the other hand, if interpretation of agent 1 50A (Figure 31 A) is resumed as a result of an agent entering 
place 220B, processing transfers from timeout step 3224 to test step 3228. In test step 3228, engine 132B 
35 (Figure 1 5E) determines whether the entering agent (not shown) is petitioned, i.e., satisfies petition 31 06 (Fig- 
ure 31 A), and is not on the list of telenames created in step 3204 (Figure 32) . If the entering agent does not 
satisfy petition 3106 (Figure 31 A) or if the telename of the entering agent is an item of the list of telenames 
created in step 3204 (Figure 32), processing transfers from test step 3228 to wait step 3222. 

If, on the other hand, the entering agent satisfies petition 3106 (Figure 31 A) and the telename of the en- 
40 tering agent is not an item of the list of telenames created in step 3204 (Figure 32), processing transfers from 
test step 3228 to a second meeting step 3230. In second meeting step 3230, the entering agent is directed to 
perform operation "meeting". Processing transfers from second meeting step 3230 to test step 3232 in which 
engine 132B (Figure 15E) determines whether performance of operation "meeting" by the entering agent suc- 
ceeded, the entering agent thereby accepting a meeting with agent 1 50A, or failed, the entering agent thereby 
45 rejecting a meeting with agent 150A. 

If performance of operation "meeting" by the entering agent succeeds, processing transfers from test step 
3232 to build contact step 3216. As described above, in build contact step 3216 and the steps that follow, a 
contact to the petitioned, i.e., entering, agent is built, the contact is pushed on to the current stack, and operation 
"meet" completes successfully. If, on the other hand, performance of operation "meeting" by the entering agent 
so throws an exception, processing transfers from test step 3232 to a second fully qualified test step 3238. 

In second fully qualified test step 3238, engine 132B (Figure 15E) determines whether petition 3106 (Fig- 
ure 31 A) is fully qualified. If petition 3106 is fully qualified, processing transfers from second fully qualified 
test step 3238 (Figure 32) to terminal step 3240 in which an exception of class "Meeting Denied" is thrown, 
causing operation "meet" as perform d by m eting place 220B to fail. 
55 Conversely, if petition 31 06 (Figure 31 A) is not fully qualified, processing transfers from second fully quali- 

fied test step 3238 to a second add agent to list step 3242. In second add agent to list step 3242, th telename 
of the petitioned, i. ., ntering, agent is added to the list of telenames creat d in step 3204. Processing transfers 
from second add agent to list step 3242 to wait step 3222 which is described above. 
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Thus a me ting is arranged between agent 1 50Aand a petitioned agent (i) which is of the name and dass 
specified by petition 31 06. (ii) which occupies the responding meeting place, and (iii) which agrees to the meet- 
ing within the maximum time period specif! d in petition 3106. The last condition permitsa first agent to request 
a meeting with a second agent which does not occupy the meeting place occupied by the first agent but which 
is expected to arrive at the meeting place within a certain amount of time. 

♦ . LT«f diat ! ly followin 9 Performance of operation "Yneet" (Figure 31B), stack 3102 contains, at its top, con- 
tact 31 08 as described above. Contact 31 08 includes a property 'subject" which is a reference to agent 150B 
( 9 . Ur ! IS Propert y " sub j ect " ** contac t 3108 (Figure 31 B) is produced by querying attribute "subject" of 
contact 3108. Attribute "subject" of a contact is described in greater detail in Appendix A. Thus, agent 150A 
featu^s* tQ a96nt 1508 (Figure 1 5E) and is therefore capable of requesting that agent 150B perform 

As discussed below in the context of operation "meeting", agent 1 50B consumes, as an argument in per- 
formance of operation "meeting", a contact which identifies agent 150A as the agent requesting a meeting 
After performance of operation "meet" by meeting place 220B. the contact consumed by agent 150B includes 
a property subject" which is a reference to agent 150A. Thus, agent 150B obtains a reference to agent 150A 
and is capable of requesting that agent 150A perform features. 

An agent, which is contacted, is a member of a class which inherits from mix-in class "Contacted" As de- 
scnbed more fully in Appendix A below, mix-in class "Contacted" defines attribute "contacts" which provides 
access to property "contacts". Property "contacts" is a set of contacts. Agent 1 50B (Figure 33) is a contacted 
agent and therefore includes property "contacts", which is set 3302. After performance of operation "meet" by 
meeting place 220B as described above, contact 3404, which is the contact consumed in performance of op- 
eration meeting" by agent 150B, is added to set 3302 by engine 132B. 

Consent of the Petitioned Agent Operation "Meeting" 

As discussed above, a petitioned agent agrees or refuses to meet with an agent requesting a meeting by 
performance of operation "meeting" by the petitioned agent. Operation "meeting" is not defined or inherited 
by class Agent". Instead, operation "meeting" is defined by mix-in class "Petitioned". Class "Agent" is note 
subclass of mix-in class "Petitioned", but subclasses of class "Agent", which are subsequently defined by users 
of the present invention, can be subclasses of mix-in class "Petitioned". Thus, only agents which are members 

*t UC l U3e ned 8ubdasses P erto "" operation "meeting" and can therefore participate in meetings 
with other agents. 8 

Figure 34A shows the execution state of agent 1 50A immediately prior to performance of operation "meet- 
ing by agent 150B. Frame 3400 is a part of the execution state of agent 150Aand records the dynamic state 
of operation meeting" as performed by agent 150B. Operation "meeting" is requested by engine 132B the 
performance of "meeting" is recorded in the execution state of agent 150A. The permit of either agent 150A 
or agent 150B. perferably agent 150B, may be debited by performance of operation "meeting". Agent 150B 
(Figure 15E) is identified within engine 132B as the responder of operation "meeting" 

Stack 3402 is property "stack" of frame 3400 and is the current stack. Immediately prior to performance 
of operation "meeting", stack 3402 contains, from top to bottom, contact 3404 and petition 3406 

Contact 3404 identifies agent 150A as the agent requesting a meeting. Property "subjectName" (not 
shown) of contact 3404 is a telename which is equivalent to the telename of agent 150A. thereby identifying 
agent 150A as the requesting agent Property "subjectQass" (not shown) of contact 3404 is a citation identi- 
fying the class of which agent 150A is an instance. Property "subject" (not shown) of contact 3404. which is 
normally a reference to agent 150A. is made nil by engine 132B. Thus, agent 150B. by consuming contact 3404 
in performance of operation "meeting", has all the information necessary to properly identify agent 150A as 
the agent requesting the meeting, but has no reference to agent 150A and therefore has no way to interact 
wrth agent 150A. In this way. neither agent can interact with the other until both have agreed to the meeting 

Petition 3406 is a copy of petition 3106 (Figure 31A) supplied by agent 150A (Figure 15E) in requesting 
the meeting, as this argument is passed "byCopy". Passing an argument "byCopy" is discussed in greater detail 
below and in Appendix A. 

♦ . o^?V 5 ° B J 9reeS to the meetina defined °y Petition 3406 (Figure 34A) with the ag nt identified by con- 
tact 3404 by performing operation "me ting" successfully. The meeting is refused by throwing an xception 
* C T' n9 °P era,ion "meeting" to fail. The method for op ration "meeting", as defined by mix-in class' 

t,tlon ed • n ver succeeds and always throws an exc ption of class "Meeting D nied". H wever, subse- 
quently d fined subclasses of class "Agent", which inh rit from mix-in class "Petitioned" can redefine th im- 
plementation of op ration "meeting" so as to succeed under certain circumstances. 

Since agents are anticipated to serv a wide variety of needs and to p rform a wide variety of services 
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the number f subclasses of class "Agent" and the variations of methods for operation "meeting" are quite large. 
For example, logic flow d iagram 3500 (Figure 35) shows one such method for op ration "m eting". In step 3502, 
contact 3404 (Figure 34A) and petiti n 3406 are popped from stack 3402. Processing transfers from step 3502 
(Figure 35) to step 3504 in which attribute "subjectClass" of contact 3404 (Figure 34A) is queried, thereby pro- 

5 ducing property "subjectClass" of contact 3404. Processing transfers from step 3504 (Figure 35) to a test step 
3506, in which property "subjectClass" of contact 3404 (Figure 34A) is compared to the citation of a specific 
class. If property "subjectClass" of contact 3404 is equal to the citation, processing transfers from test step 
3506 (Figure 35) to terminal step 3508. In terminal step 3508, operation "meeting" completes successfully and 
the meeting is thereby agreed to. Otherwise, if property "subjectClass" of contact 3404 (Figure 34) is not equal 

10 to the citation, processing transfers from test step 3506 (Figure 35) to terminal step 351 0 in which an exception 
of class "Meeting Denied" is thrown causing operation "meeting" to fail, thereby rejecting a meeting with the 
agent identified by contact 3404 (Figure 34A). 

As discussed above, contact 3404, which identifies agent 150Aand is supplied to agent 150B (Figure 15E) 
as an argument in requesting performance of operation "meeting", contains no reference to agent 150A. In- 

15 stead, property "subject" of contact 3404 (Figure 34A) is nil. Once a meeting is successfully arranged by per- 
formance of operation "meet" by meeting place 220B (Figure 15E) as described above, engine 132B modifies 
property "subject" of contact 3404 (Figure 34A) to be a reference to agent 150A. 

Thus, the full generality and data processing capabilities of the computer instruction set described in Ap- 
pendix A can be used to apply sophisticated logic, processing substantial amounts of data, to determine with 

20 which agents and under what circumstances specific agents are configured to agree to a meeting. 

Figure 34B shows the state of frame 3400 immediately following performance of operation "meeting" by 
agent 150B (Figure 15E). Stack 3402 (Figure 34B) is empty as operation "meeting" produces no result The 
access of operation "meeting" is "system"; only an engine is capable of requesting operation "meeting". It 
should be noted that operation "meeting" defined by mix-in class "Petitioned" is distinct and separate from op- 

25 eration "meet" defined by class "Meeting Place" which is discussed above and in Appendix A. 

Terminating Interaction Between Agents; Operation "Part" 

As described above, two agents exchange references to each other and to objects owned by either agent 

30 during the course of a meeting between the two agents. Terminating interaction between the agents requires 
ensuring that neither agent contains a reference to the other agent or references to objects owned by the other 
agent. Either agent participating in a meeting between two agents occupying a meeting place can terminate 
the meeting by requesting performance of operation "part" by the meeting place. Agents 150Aand 150B which 
occupy meeting place 220B and which are interpreted by engine 132B (Figure 15E), are shown in Figure 36. 

35 Agent 150A has obtained reference 150A-R1 to agent 150B, and agent 150B has obtained reference 150B- 
R1 to agent 150 A, by the successful performance of operation "meet" by meeting place 220B. Object 3602 is 
owned by agent 150 A. Similarly, object 3604 is owned by agent 150B. Figure 36 shows the state of agents 
150Aand 150B after agents 150Aand 150B have interacted and exchanged references to objects 3602 and 
3604. By giving to agent 1 50B a reference to object 3602, agent 1 50A grants agent 1 50B access to object 3602. 

40 Such access by references 150B-R1 and 150B-R2 enables agent 150B to issue instructions to engine 132B 
which cause agent 150Aand object 3602, respectively, to take action in accordance with the instructions is- 
sued. Similarly, agent 150B gives to agent 150A reference 150A-R2 to object 3604, thereby granting to agent 
1 50A similar access to object 3604. 

Agent 150A contains references 150A-R1, 150A-R2 and 150A-R3 to agent 150B, object 3604, and object 

45 3602, respectively. References 150A-R1 . 1 50A-R2 and 1 50A-R3 are (i) contained either within a stack or within 
a list of variables (neither shown) of a frame (also not shown) which is part of the execution state of agent 1 50A 
or (ii) stored as a property, or as a component of a property, of agent 150A. The execution state of an agent 
is discussed in detail below. Agent 150B similarly contains references 150B-R1, 150B-R2 and 150B-R3 to 
agent 150A, object 3602, and object 3604, respectively. By giving to agent 1 50A reference 150A-R2 to object 

so 3604, agent 1 50B allows agent 150A(i) to request that object 3604 perform an operation or (ii) to copy a portion 
or all of object 3604. 

Either agent 150A or agent 150B is capable of terminating th interaction between agents 150Aand 150B 
by requesting that meeting place 220B perform operation "part". For illustration purposes, agent 150A is the 
agent which requests that meeting place 220B perform operation "part". Figures 37Aand 37B illustrate th 
55 state of agent 1 50A immediately prior to and following, respectively, performance of peration "part" by meeting 
place 220B. Frame 3702 is a part of the xecution state of agent 1 50A and records the state of op ration "part" 
as performed by meeting place 220B. Meeting place 220B is property "responder" f frame 3702 and is there- 
f re the responder of operation "part". Stack 3704 is property "stack" of frame 3702, which is also part of the 
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ex cution state of ag nt 150A, and is th curr nt stack. 

At the top of stack 3704 is contact 3706. Contact 3706 identifies ag nt 150B as the ag ntfrom which agent 
1 50A is to part. Engine 1 32B (Figure 1 5E), in carrying out performance of operation "part" on behalf of meeting 
place 220B, directs agent 150B to perform operation "parting". Agent 150B consumes as the sole argument 
5 a contact identifying agent 1 50A as the agent with whom agent 1 SOB is parting. Property "subject" of the con- 
tact, which is usually a reference to agent 1 50A is voided by engine 1 32B prior to requesting operation "parting" 
so that agent 150B is not left with a reference to agent 150A after the meeting is terminated. 

In performing operation "parting 0 , agent 150B produces no result The dynamic state of performance of 
operation "parting" is not part of the execution state of either agent 1 SOB (Figure 15E) or agent 150A, but is 
10 instead part of the execution state of an engine process. Any exception thrown by performance of operation 
"parting" is not experienced by, and therefore has no effect upon, either agent 150B or agent 150A. In per- 
forming operation "parting", agent 1 SOB is notified that agent 1 50Ahas terminated the meeting between agents 
1 50A and 150B. If agent 150B is a contacted agent, the item of property "contacts" of agent 1 50A that is the 
contact referencing agent 150A is removed from property "contacts" of agent 150B. The access of operation 
15 "parting" is "system"; therefore, only engine 1 32B can request that agent 150B perform operation "parting". 

Figure 37B illustrates the state of agent 150A immediately following performance of operation "part" by 
meeting place 220B. Stack 3704 is empty as operation "part" produces no result. 

Terminating a meeting between agents ISOAand 150B voids all references in agent 150A to agent 150B 
and all objects owned by agent 150B. For example, in Figure 38, reference 150A-R1 that previously identified 
20 agent 150B and reference 150A-R2 that previously identified object 3604 are voided. Similarly, reference 
1 50B-R1 that previously referenced agent 1 50A and reference 1 50B-R2 that previously referenced object 3602 
are voided within agent 150B as well. Thus, agents 150A and 150B are no longer capable of exchanging in- 
formation. If agents 150Aand 150B are contacted agents, a contact identifying agent 150A is removed from 
property "contacts" of agent 150B, and a contact identifying agent 150B is removed from property "contacts" 
25 of agent 150A. 

Applicability of the Present Invention to Large, Wide-Area Networks 

Thus far, a communications system is disclosed in which agent 150A (Figure 15A) transports itself, or a 

30 clone of itself, to meeting place 220B, which is occupied by agent 1 SOB, by performance of operation "go" or 
operation "send", respectively. Agent 150A then requests performance of operation "meet" by meeting place 
220B to arrange a meeting between agent 150 A and agent 150B. During the meeting, agents 150A and 150B 
are capable of exchanging information as described in greater detail below. 

While the foregoing discussion pertains to a very simple use of the present invention, much more general 

35 uses can be made of the present invention. Through application of the set of computer instructions described 
herein and in Appendix A, an agent is capable of applying sophisticated and complex logic to determine to what 
places to transport itself and with which other agents and places to meet and exchange information. 

Additionally, the present invention is not limited to networks of two or three computer systems, as described 
herein, and as previously stated, the present invention is not limited to homogenous networks. The set of com- 

40 puter instructions described herein and in Appendix A can be used to create and position places throughout a 
large area network such that agents can be created which travel throughout the large area network. As the 
disclosed instruction set can be implemented in heterogenous networks, the wide area network can include 
a wide variety of computer systems including large, mainframe computers; local area networks; and small per- 
sonal computers through which an agent in the wide area network can travel. 

45 Furthermore, while a meeting is defined as an interaction between two agents, an agent is capable of par- 

ticipating in any number of meetings simultaneously and is therefore capable of interacting with a multitud 
of agents simultaneously, as long as those agents occupy the same meeting place occupied by the first- 
mentioned agent. 

50 Interaction between Agents; Introduction to the Execution Model 

During a meeting between agent ISOAand agent 1 SOB, agent 150A (Figure 15E) interacts with agent 150B 
by issuing an instruction directing ag nt 150B to perform a feature. The following describes the mechanism 
by which performance of a feature is requested; this mechanism is discussed in greater detail below and in 
55 Appendix A. 

An execution state is associated with each process. As discussed above in the Glossary of Terms, each 
method has a dynamic state during performance of th meth d. The execution state of a process includ s one 
or more frames, each frame recording the dynamic state of a method which is part of the execution state f 
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the process. Within each frame is a stack on to which arguments are pushed prior to requesting operations, 
and from which results are popped after performance of operations. The stack of th current frame is the cur- 
rent stack. The current frame is th frame which contains the computer instruction whose xecution is currently 
being carried out by an engine. 
5 Prior to requesting an operation, the requester pushes on to the current stack references to zero or more 

objects which are thereby supplied as arguments for the operation. The requester then pushes on to the current 
stack a reference to the responder. The responder is the object which is directed by the requester to perform 
the requested operation. Finally, the requestor requests the execution of an identifier which identifies the re- 
quested operation. 

10 In carrying out performance of the requested operation, an engine pops an object from the top of the cur- 

rent stack, and the object is made the responder of the operation. Amethod implementing the operation is found 
within the classes of which the responder is a member and performed. In one embodiment, performance of 
the method (i) forms a new stack, (ii) pops the arguments of the operation from the current stack and pushes 
them on to the new stack, (iii) makes the new stack current, (iv) pops arguments from the new current stack, 

is (v) pushes a result, if one is produced by the operation, on to the new current stack, and (vi) pops the result, 
if any, from the new current stack and pushes the result, if any, on to the previously current stack. The execution 
of operations, and features in general, is discussed in greater detail below and in Appendix A. 

The following example illustrates the mechanism by which operations are requested. As discussed above, 
during the course of a meeting, agent 150A interacts with agent 150B by directing agent 150B to perform an 

20 operation. Agent 1 50A grants agent 1 50B access to objects contained within agent 1 50A by supplying those 
objects as arguments to the operation requested. Agent 1 50B grants agent 1 50A access to an object contained 
within agent 150B by producing that object as a result of the requested operation. 

Figures 39A-39F illustrate an example of agent 150A (Figure 15E, not shown in Figures 39A-39F) inter- 
acting with and passing information to agent 150B. 

25 Figure 39A shows empty stack 3902. Stack 3902 is the current stack of the execution state of agent 150A 

(not shown). While Figure 39A shows stack 3902 as being empty, such need not be the case. However, no 
objects on stack 3902 in Figure 39Aare affected by this example. String 3904 whose text is "this is a message" 
is pushed on to stack 3902 (Figure 39B). A reference to agent 150B is pushed on to stack 3902 (Figure 39C). 
Agent 150A next executes an identifier whose text is "store" and which references an operation "store". 

30 In execution of the identifier, an object, i.e. agent 150B, is popped from stack 3902 and the object is directed 
to perform operation "store" (Figure 39D). In this example, operation "store" is defined for a class of which agent 
1 50B is a member and whose method is represented by logic flow diagram 4000 (Figure 40). 

In performing operation "store", agent 150B pops string 3904 from stack 3902 in step 4002 (Figure 40). 
Although agent 150B is described as performing operation "store", the frame (not shown) which records the 

35 dynamic state of agent 150B's performance of operation "store" is part of the execution state of agent 150A 
(not shown). The charges allowance, i.e., property "charges", of the permit of agent 150A is therefore debited 
for processing resulting from performance of operation "store" by agent 150B. Agent 150B is the object per- 
forming operation "store" since (i) the execution state of agent 1 50A (not shown) identifies agent 1 SOB as th 
responder and since (ii) the method of operation "store" is provided by a class of which agent 1 50B is a member 

40 and (iii) the internal state of agent 150B provides a context within which operation "store" is performed. 

Processing transfers from step 4002 to step 4004 in which string 3904-C, which is a copy of string 3904, 
is created, resulting in the state shown in Figure 39E. Strings 3904 and 3904-C are contained within frame 
3906 which is part of the execution state of agent 1 50A and which records the dynamic state of operation "store" 
as performed by agent 1 50B. Processing transfers from step 4004 to step 4006 (Figure 40) where agent 150B 

45 stores string 3904-C. Processing transfers from step 4006 to step 4008 in which agent 150B discards string 
3904. which was popped from stack 3902. Processing transfers from step 4008 to terminal step 4010 in which 
operation "store" completes successfully. Step 4008 results in the state represented by Figure 39F. Thus, agent 
150A has successfully transferred information to agent 150B. 

In this manner, agent 150A interacts with agent 150B by agent 150A requesting agent 150B to perform 

50 an operation, and agent 150A conveys to agent 150B objects as arguments to or results from operations re- 
quested or performed, respectively. While agent 150B is described as performing an operation at the request 
of agent 150A, it is reit rated here that performance of a feature by an object is, in actuality, performance of 
the feature by an engin in the context of that object defined by that object's internal state and class. The be- 
havior of a particular feature can vary depending on the internal state of the object performing th feature, 

55 where the internal state of the bject is defined in part by th objects properties. 

Ag nt 150B can similarly transfer an object to agent 150A by pushing the object on to stack 3902, e.g., 
after step 4008 and before terminal step 4010. The object is p pped from stack 4010 as a result of operation 
"store" by agent 150A Furthermore, since agent 150B contains a reference to agent 150A, as discussed abov 
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with respect to operation "meet", agent 150B is similarly capable of directing agent 150A to perform an oper- 
ation and of supplying to agent 150A objects as argum nts to the operation. 

Portability of the Computer Instruction Set of the Present Invention 

A number of aspects of the present invention permit processes a great deal of mobility and versatility. First, 
the computer instruction set of the present invention is homogeneously implemented in a homogeneous or 
heterogenous network. Second, classes are objects of the computer instruction set so that classes can trav I 
throughout the network with mobile processes. And third, the computer instruction set is interpreted. 

Homogeneity of the Computer Instruction Set 

As discussed above, an agent, which includes data and computer instructions, is capable of traveling from 
one computer system to another and of executing on whichever computer system the agent may be found. 
15 Furthermore, the network throughout which agents are capable of traveling can be either homogeneous or 
heterogeneous. In view of the mobility of agents, it is not always possible to determine exactly which computer 
system of the network executes each of the computer instructions forming the procedural portion of an agent. 
It is therefore important that each computer system of the network, throughout which agents can travel, sup- 
ports the same computer instruction set 
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Classes Represented as Objects in the Disclosed Computer Instruction Set 

An agent executing within a first computer system is capable of creating new classes of objects which did 
not previously exist. The agent can then travel to an engine which is executing within a second computer system 
and interpretation of the agent, involving processing of members of the newly created class, continues within 
the second computer system. In such a case, the engine executing within the second computer system has 
never before encountered the newly created class or any members of that class. Therefore, classes are made 
objects of the disclosed instruction set so that classes are capable of traveling with agents from one computer 
system to another. 

Class Structure 



Several objects combine to define and represent a class: a class object, an identifier, and a class definition. 
Class objects, identifiers and class definitions are members of the respective classes "Class", "Identifier" and 

35 -Class Definition". Class objects, i.e., members of class "Class", are objects which represent a set of objects 
whose features have the same interface and implementation. The set of objects are the "instances" of the class. 
Class "Class" and class objects are discussed in greater detail below and in Appendix A. 

Identifiers, i.e., members of class "Identifier", are used within an interface object or an implementation 
object to reference a class. It should be noted that identifiers reference other types of objects as well. Interface 

40 objects and implementation objects are discussed below in greater detail. A first identifier referencing a first 
class within a first interface object or implementation object is distinct from identifiers referencing all other 
classes within the first interface object or implementation object However, a second interface object or im- 
plementation object can use an identifier equivalent to the first identifier to reference a second class. 

An interface object and an implementation object together define a number of features, i.e., operations 

45 and attributes. The distinction between an attribute, in which case an object is directed to provide or alter a 
portion of the object's internal state, and an operation, in which case an object is directed to perform a number 
of computer instructions, serves primarily to aid in conceptualization of the present invention. Conceptually, 
an attnbute is a special case of an operation. For example, querying an attribute of an object directs the object 
to perform computer instructions which cause the object to provide information regarding the internal state of 

50 the object. 

It is reiterated here that performance of a feature by an object is, in actuality, performance of the feature 
by an engine in the context of that object defined by that object's internal state and class. Th behavior of a 
particular feature can vary depending on the internal stat of the object performing the feature, wh reth in- 
t rnal state of the object is defined in part by the object's properties. 
55 A single id ntif ier can simultaneously identify two s parate features, each feature defined by a different 

class. For example, op ration "add" is defined by class "Number" differently than by class "Dictionary". In se- 
lecting an interface and implementation, the engine carrying out performance of a feature selects the feature 
definition and associated method object appropriate for the class of object performing the feature. In other 
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words, the feature definition is retriev d from the classes of which the responder is a member. Aconcret class 
defining a feature defines both th feature's interface and the feature's impl mentation. An abstract class 
which defines a feature defines the f ature's interface and can define the feature's implementation. 

The "interface" of a feature defines the arguments consumed in performance of the feature as well as th 

5 result produced, if any. Additionally, the exceptions which can be produced by a feature are defined by the 
feature's interface. The interfaces of the features defined by a class are collectively represented and defined 
by an interface object, i.e., a member of class "Interface", which is property "interface" of a class definition 
object. Class "Interface" is discussed below in more detail. 

A feature's implementation is defined by the feature's "method. 0 A feature's method defines actions to be 

10 taken, i.e. computer instructions to be executed, in performance of the feature. A method object, a member of 
class "Method", is generally a sequence of instructions whose execution constitutes performance of the fea- 
ture. The implementations of the features defined or inherited by a class are collectively represented and de- 
fined by an implementation object, i.e., a member of class "Implementation", which is property "implementa- 
tion" of a class definition object. Class "Implementation" is discussed below in more detail. 

15 Feature definitions are inherited from a class's superclasses. In other words, if a feature is defined for a 

particular class, that feature is also defined for that class's subclasses. However, a subclass is capable of re- 
defining the implementation of the feature, superseding the implementation inherited from the superclass. 
However if the feature is "sealed" by a superclass of the subclass for which the feature is defined, the subclass 
cannot redefine the implementation inherited from the superclass. 

20 The features defined by a class are defined by the class's class definition, a member of class "Class Def- 

inition". The class itself is represented by a class object, a member of class "Class". The class is referenced 
by an identifier, a member of class "Identifier". 

A class Is created by first creating a class definition, the structure of which is discussed in Appendix A. 
The class definition is directed to perform operation "makeClasses" to create an associated class object. Th 

25 syntax and behavior of operation "makeClasses" is discussed in more detail in Appendix A. The particular form 
and structure of the formed class object is not essential so long as (i) the information contained within the class 
definition object is preserved and (ii) citation 4108 (Figure 41A), interface object 4110, and implementation 
object 4112 can be derived from the class object Condition (ii) is necessary for the encoding of a class object 
as described in Appendix B. 

30 The engine carrying out performanceof operation "makeClasses 0 on behalf of class definition 41 00 (Figure 

41A), in one embodiment, forms class object 4102 (Figure 41B) by replicating in class object 4102 the prop- 
erties of class definition 4100. After performance of operation "makeClasses", class definition 4100 is discard- 
ed. The properties of class definition 4100 are discussed in greater detail below. As the properties of class 
definition 4100 are replicated in class object 4102, class object 4102 contains all of the information contained^ 

35 in class definition object 4100 and can derive the properties of class definition object 4100. 

In another embodiment, processing efficiencies of compiled computer processes are realized by replicat- 
ing information in citation 41 08, interface object 4110 and implementation object 41 1 2 to form citation structure 
4108C (Figure41C), interface structure 4110C and implementation structure 41 12C, respectively, within class 
object 4104. Computer processes which are formed of computer instructions which are compiled, rather than 

40 interpreted, are generally more efficient, i.e., perform a given task within a fewer number of CPU clock cycles, 
than computer processes whose instructions are interpreted. As discussed above, computer instructions are 
initially in human-intelligible source code. Before a computer instruction can be executed by a computer, the 
instruction must be translated into a computer-intelligible object code or machine code. As interpreted computer 
processes require such translation for each computer instruction executed, and as compiled computer proc- 

45 esses do not require such translation during execution of a compiled computer process, compiled computer 
processes can be substantially more efficient than interpreted computer processes. 

Citation structure 4108C. interface structure 4110C and implementation structure 4112C are objects 
which are analogous to citation 4108, interface object 4110 and implementation object 4112 and which are 
formed of compiled computer instructions such the computer instructions which collectively form the C++ pro- 

50 gramming language. By replicating the structures of citation 4108, interface object 41 10, and implementation 
object 4112 (Figure 41 A) in class object 4104 (Figure 41 C) as citation structure 4108C, interface structure 
4110C, and implementation structure 4112C, respectively, information regarding the class represented by 
class object 41 04 can be retrieved substantially more efficiently than by retrieving th inf rmation from citation 
4 1 08, interface object 41 1 0 and implementation object 41 1 2 of class object 41 02 (Figure 4 1 B). Th information 

55 contained within citation structure 4108C (Figure 41 C), interface structure 411 0C, and implementati n struc- 
ture 4112C is substantially equivalent to the information contained within the corresponding properties of class 
definition 4100 (Figure 41A). 

As the information contained within a class object is substantially equivalent to the information contained 
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within the class definition from which the class object is derived, discussion of the structure of a class definition 
also describes th nature of the information contained within a class object. 

Class Definition Objects 

5 

The features defined by a class are defined in the class definition object which defines the class. The struc- 
ture of class definition object 4100 is shown in Figure 41 A. Class definition object 4100 includes properties 
"citation", "interface" and "implementation". Citation 4108 is property "citation" of class definition object 4100 
and identifies the class defined by class definition object 4100 and further identifies the authority, title and 
10 edition of the class. The structure of a citation is discussed in greater detail below and in Appendix A. 

Interface object 4110 and implementation object 4112 are, respectively, properties "interface" and "imple- 
mentation" of class definition object 4100. Interface object 411 0 defines the interfaces of the features defined 
by class definition object 4100, and implementation object 4112 defines the implementations of the features 
defined by class definition object 4100. 

15 

Interface objects 

The structure of interface object 4 1 1 0 is shown in Figure 42. The properties of interface object 41 1 0 include 
properties "isAbstract", "classFeatures", "sealedClassFeatures", "instanceFeatures", "sealedlnstanceFea- 
20 tures", "Vocabulary" and "superclasses". 

Boolean 4208 is property "isAbstract" of interface object 411 0. If boolean 4208 is "true", the class, whose 
interface is interface object 4110, is abstract. The class is concrete otherwise. 

Lexicon 4210 is property "classFeatures" of Interface object 4110. Lexicon 4210 is a lexicon of the defi- 
nitions of the "class features" of the class. The class features of a class are the features for which the class 
25 itself, i.e., the class represented by class definition object 4100 (Figure 41 A), is the responded The keys of 
lexicon 421 0 (Figure 42), e.g., identifier 421 OK, are identifiers which reference the class features. The values 
of lexicon 421 0, e.g., feature definition 421 0V, are feature definitions defining the class features. Feature def- 
initions are discussed below in more detail. 

Set 4212 is property "sealedClassFeatures" of interface object 411 0. Set 4212 is a set of identifiers, e.g., 
30 identifier 42121, which reference the class features which are sealed. Sealed features are features that sub- 
classes are prevented from adapting. If a feature is not sealed, a subclass of the class represented by class 
definition object 4100 (Figure 41 A) can adapt the feature by redefining the feature's implementation. 

Lexicon 4214 (Figure 42) is property "instanceFeatures" of interface object 411 0. Lexicon 4214 is a lexicon 
of the definitions of the "instance features" of the class. The instance features of a class are features for which 
35 members of the class are the responder. The keys of lexicon 4214 (Figure 42) (no key or value of lexicon 4214 
is shown) are identifiers referencing the instance features, and the values of lexicon 4214 are feature defini- 
tions defining the instance features. 

Set 4216 is property "sealedlnstanceFeatures" of interface object 4110. Set 4216 is a set of identifiers 
(not shown) which reference the instance features which are sealed. 
40 Lexicon 4218 is property 'vocabulary" of interface object 4 110. Lexicon 421 8 associates identifiers of user- 

defined classes which are referenced in interface object 41 1 0 with citations of those classes. The keys of lex- 
icon 4218 are identifiers, e.g., identifier 421 8K, and the values of lexicon 4218 are corresponding citations, 
e.g., citation 4218V. Citations are discussed in greater detail below and in Appendix A. Property "vocabulary" 
of interface object 4110, i.e., lexicon 4218, is "the vocabulary" of interface object 4110 and of the class defined 
45 by class definition object 4100 (Figure 41A). 

List 4220 (Figure 42) is property "superclasses" of interface object 4110. List 4220 is a list of identifiers, 
e.g., identifier 4220I, which reference classes. The classes referenced by identifiers of list 4220 are immediate 
interface superclasses of the class defined by class definition object 41 00 (Figure 41 A) . All but the last item 
of list 4220 (Figure 42) must identify mix-in classes, and the last item of list 4220 must identify a flavor. The 
so importance of the last item of list 4220 identifying a flavor is discussed below in more detail in conjunction 
with the selection of a method object in performing a feature and in conjunction with object initialization. 

Feature Definitions 

55 A feature definition, i.e., am mberof class "Feature", is an objectwhich defines the interfaceof a particular 

feature. The properties of feature definition 4210V (Figure 43) include properties "exceptions" and "isPublic". 
Class "Feature" is abstract; therefore, feature definition 421 0V is a member, not an instance, of class "Feature" 
and is either an operation definition or an attribute definition, both of which are described below and in Appendix 
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A. Set 4302 is property "exceptions" of f atur definition 421 0V. S 1 4302 is a set of identifiers, .g„ identifier 
4302I, which each reference a class of which exceptions thrown by the feature defined are members. When 
the feature defined by feature definition 4210V throws an exception, th exception is verified to be a member 
of one of the classes referenced by an identifier of set 4302. If the exception is not a member of a class ref- 
erenced by an identifier of set 4302, a member of class "Unexpected Exception" is thrown in place of the ex- 
ception. Otherwise, the exception is thrown. 

Boolean 4304 is property "isPublic" of feature definition 4210V. Boolean 4304 indicates whether the fea- 
ture defined by feature definition 4210V is a public feature or a private feature, i.e. whether the access of the 
feature defined is "public" or "private". Each feature has an associated "access" which determines which ob- 
jects and under what circumstances each feature can be properly requested. The access of each feature of 
this invention is disclosed in Appendices A and B. 

If boolean 4304 is "true", the feature is public. A feature whose access is public can be requested by any 
object If boolean 4304 is "false", the feature is private. A feature whose access is private can only be requested 
by the responder, i.e., an object can only request the feature of itself. System features, i.e. f features whose 
access is "system", are all predefined and therefore are not defined by feature definitions. Predefined features 
are implemented within an engine and therefore are not represented by objects such as feature definitions. 
One implementation of an engine of one embodiment of the present invention, which implements the disclosed 
predefined features, is disclosed in the software of Appendix G which is incorporated herein in its entirety by 
reference. 

Attribute Definitions 

A feature definition that defines an attribute is an attribute definition, i.e., a member of class "Attribute". 
Therefore, class "Attribute" is a subclass of class "Feature". As an attribute definition is a feature definition, 
an attribute definition inherits the properties defined or inherited by class "Feature" as described above. In 
addition, attribute definition 4400 (Figure 44) includes properties "constraint" and "isSet". 

Constraint 4402 is property "constraint" of attribute definition 4400. Constraint 4402 constrains objects 
representing the attribute defined by attribute definition 4400. As discussed below in greater detail, a constraint 
places restrictions on an object and can restrict (i) the class of which the object is a member, (ii) whether th 
object must be an instance of the class, (iii) whether the object can be a nil and (iv) how the object is passed 
between a feature's requester and responder. 

Boolean 4404 is property "isSet" of attribute definition 4400. Boolean 4404 indicates whether the attribut 
defined by attribute definition 4400 can be set as well as queried. If boolean 4404 is "true", attribute definition 
4400 defines an attribute which can be set. Otherwise, the attribute defined by attribute definition 4400 can 
only be queried. 

Operation Definitions 

As discussed above, a feature is either an attribute or an operation. Therefore, a second subclass of class 
"Feature" is class "Operation". An operation definition, i.e., a member of class "Operation", defines the inter- 
face of an operation. 

Figure 45 shows the structure of operation definition 4500. As an operation definition is a feature definition, 
operation definition 4500 includes the properties defined or inherited by class "Feature" as described above. 
In addition, operation definition includes properties "arguments" and "result". 

List 4502 is property "arguments" of operation definition 4500. Property "arguments" of an operation def- 
inition is optional, i.e., property "arguments" of an operation definition can be a nil rather than a list. If property 
"arguments" is a nil, the operation defined by operation definition 4500 consumes a variable number of argu- 
ments. The performance of an operation whose arguments are variable in number is described in Appendix 
A. Conversely, if property "arguments" is list 4502, the number of arguments consumed by the operation de- 
fined by operation definition 4500 consumes a fixed number of arguments, the number being equal to th 
length of list 4502. If property "arguments" is an empty list, the operation consumes no arguments. The items 
of list 4502, e.g., constraint 4502I, are constraints which constrain the arguments of the operation defined by 
peration definition 4500. As discussed bel w with respect to Figure 46, a constraint constrains an object's 
class and passage. 

Constraint 4504 is property "result" of operation definition 4500. Constraint 4504 constrains the result of 
the operation defined by operation definition 4500. Property "result" of an operation definition is also optional. 
If prop rty "result" is a nil rather than constraint 4504, then the peration defined by operation definition 4500 
produces no result 
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Constraints 

As discussed above, a constraint restricts the class and passage of an object. Th structure of constraint 
4402 is shown in Figure 46. The properties of constraint 4402 include properties "classld", "ofCiass", "isln- 
5 stance", "isOptional", and "passage". 

Properties "ofClass" and "classld" are alternative ways for specifying the class of which the constrained 
object must be a member. Class object 4602 is property "ofClass" of constraint 4402. Class object 4602 rep- 
resents the class of which an object upon which constraint 4402 is imposed must be a member. Property "of- 
Class" is optional and, therefore, can be a nil. If property "ofClass" is nil, the class of which the object must 
10 be a member is referenced by identifier 4610 which is property "classld" of constraint 4402. 

Property "ofClass" is a class object and therefore can only be a class which exists at the time constraint 
4402 is created. However, requiring that a property of a constraint is a class which exists prevents users of 
the present invention from defining multiple interdependent classes. For example, a constraint in a feature def- 
inition of a first class can refer to a second class and a second constraint in a second feature definition in the 
15 second class can refer to the first class. Providing property "classld" of constraint 4402 as an alternative to 
property "ofaass" enables users to define multiple interdependent classes simultaneously. 

Boolean 4604 is property "islnstance" of constraint 4402. Boolean 4604 indicates whether an object upon 
which constraint 4402 is imposed must be an instance of the class represented by class object 4602. If boolean 
4604 is "true", the constrained object must be an instance of the class. Otherwise, the constrained object's 
20 membership in the class is sufficient to satisfy constraint 4402. 

Boolean 4606 is property "isOptional" of constraint 4402. Boolean 4606 indicates whether a nil object sat- 
isfies constraint 4402, properties "ofClass" and "classld" notwithstanding. If boolean 4606 is "true", a nil object 
satisfies constraint 4402. As illustrated in numerous examples herein, a nil object can be placed on a stack In 
lieu of an omitted optional argument or result of a feature. 
25 Identifier 4610 is property "passage" of constraint 4402. Identifier 46 10 indicates in what manner an object 

on which constraint 4402 is imposed is passed as a parameter, i.e., as an argument or result Identifier 4610 
has four possible values: "byRef", "byUnprotectedRef", "byProtectedRefand "byCopy". Setting identifier 4610 
to a value other than one of these four throws an exception that is a member of class "Passage Invalid". 

In passing a reference to an argument between the requestor of a feature and the responderof the feature, 
30 an engine takes a source reference to the argument from the requestor and provides a destination reference 
to the responder. In passing a reference to a result, the source reference is taken from the responder and a 
destination reference is provided to the requestor. 

If the parameter is passed a byRef\ the source reference and the destination reference are the same. If 
the parameter is passed "byUnprotectedRef", an exception of class "Reference Protected" is thrown if th 
35 source reference is a protected reference; otherwise, the destination reference is the source reference. If the 
parameter is passed "by Protected Ref", the destination reference is a protected reference to the object refer- 
enced by the source reference. If the parameter is passed "byCopy", the destination reference is an unprotected 
reference to a copy of the object referenced by the source reference. Passage of parameters is discussed fur- 
ther in Appendix A. 

40 Thus, constraint 4402 (Figure 44) restricts the class and passage of an object 

Implementation Object 

As discussed above, implementation object 4112 (Figure 41A) defines the class implementation of th 
45 class defined by class definition object 4100. A class implementation defines the following: (i) zero or more 
properties of the members of the class defined; (ii) the respective implementations of the various class features 
and (iii) instance features defined by a class; (iv) methods for setting attributes defined for the class; (v) meth- 
ods for converting objects from the class defined to a second class; (vi) methods for converting objects from 
a second class to the class defined; (vii) definitions of identifiers used to define classes; and (viii) the imple- 
50 mentation superclasses of the class defined. 

List 4702 (Figure 47) is property "properties" of implementation object 4112. List 4702 defines the prop- 
erties that implementation object 4112 implements. Th it ms of lexicon 4702, .g., identifier 4702I, are id n- 
tif i rs of the properties defined by implementation object 4702. 

Lexicon 4704 (Figure 47) is property "classMethods" of implementation object4112. Lexicon 4704 provides 
55 methods forth class features of the class repres nted by class definition object 41 00 (Figure 41 A). Th keys 
of lexicon 4704, e.g., identifier 4704K (Figure 47), are id ntif iers of the class features, and the values of I xicon 
4704, ,g., method object 4704V, are method objects which define the impl mentation of the class features. 

A method object, i. ., a member of class "Method", is an object which defines the method of a feature. 
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The method of a feature is the particular series of steps tak n by an engin , and therefore th comput r system 
within which th engin is xecuting, in carrying out performance of the feature. 

A method is def in d in terms of the disclosed instruction set as the instruction set is amended by any user- 
defined classes or features. Method objects are discussed in greater detail below and in Appendix A. 
5 Lexicon 4706 is property "instanceMethods" of implementation object 4112. Lexicon 4706 associates iden- 

tifiers of instance features with corresponding method objects, which in turn define the implementation of the 
instance features. The structure of lexicon 4706 is similar to the structure of lexicon 4704 and that discussion 
is incorporated herein by reference. 

Lexicon 4707 is property "setMethods" of implementation object 41 1 2. Lexicon 4707 associates identifiers, 
10 which identify respective attributes, with method objects. Each of the method objects of lexicon 4707 imple- 
ments the attribute of the corresponding identifier when executed in the presence of a "set" modifier. In other 
words, each method object of lexicon 4707 defines the implementation of the setting of a corresponding at- 
tribute. The execution of an attribute in the presence of a "set" modifier is discussed in Appendix A. 

Lexicon 4708 is property "fromMethods" of implementation object 4112. Lexicon 4708 associates identi- 
is f iers with method objects. Each identifier references a class and is associated with a method object which pro- 
vides the implementation of the conversion from the referenced class to the class defined by class definition 
object 4100 (Figure 41 A), i.e., the class whose implementation is implementation object 4112 (Figure 47). 

Lexicon 471 0 is property "toMethods" of implementation object 4112. Lexicon 4710 associates identifiers 
with method objects. Each identifier references a class and is associated with a method object which provides 
20 the implementation of the conversion to the referenced class from the class defined by class definition object 
4100 (Figure 41 A), i.e., the class whose implementation is implementation object 41 12 (Figure 47). The struc- 
ture of lexicons 4707, 4708 and 4710 is similar to the structure of lexicon 4704 and that discussion is incor- 
porated herein by reference. 

Lexicon 4712 is property "vocabulary" of implementation object 41 12. Lexicon 4712 defines the identifiers 
25 used by implementation object 4112 to identify classes. The keys of lexicon 4712, e.g., identifier 4712K, are 
identifiers used within implementation object 4112 to identify specific user-defined classes. The values of lex- - 
icon 4712, e.g., citation 471 2V, are corresponding citations which identify the class identified by the associated 
identifier. Lexicon 4712 provides a translation between an identifier used to identify a user-defined class within 
implementation object 4112 and a citation used to identify the class throughout the network. Citations are dis- 
30 cussed in greater detail below and in Appendix A. 

List 4714 is property "superclasses" of implementation object 4112. The items of list 4714, e.g., identifier 
47141, are identifiers which identify the implementation superclasses of the class defined by class definition 
4100 (Figure 41 A). List 4714 (Figure 47), i.e. property "superclasses" of implementation object 4112, can con- • 
tain identifiers of classes which are not items of list 4220, i.e. property "superclasses" of interface object 4110. 
35 For example, a first class may benefit from the ability to use features of a second class in implementing fea- 
tures of the first class. However, in designing such a class, it is not always preferred that the features of the 
second class are themselves inherited by the first class. In such cases, the second class is made an imple- 
mentation superclass but not an interface superclass of the first class. 

Thus, implementation object 4112 defines, for the class defined by class definition object 4100 (Figure 
40 41 A), (a) properties of the members of the class defined, (b) the class and instance feature methods, (c) meth- 
ods for setting attributes, (d) methods for conversion to and from the class defined, (e) identifiers used to iden- 
tify classes, and (f) implementation superclasses. 

Method Objects 

45 

As discussed above, a method object defines the computer instructions executed in performance of a fea- 
ture or a conversion. Figure 48 shows the structure of method object 4800. Properties of method object 4800 
include properties "procedure" and "variables". Procedure 4802 is property "procedure" of method object 4800. 
Performance of procedure 4802 constitutes performance of the feature or a conversion implemented by meth- 

so od object 4800. Procedures are discussed in more detail below. 

List 4804 is property "variables" of method object 4800. List 4804 defines the variables that are used by 
procedure 4802. The it ms of list 4804, e.g., identifier 4804I, are identifiers which reference the variables de- 
fined for method object 4800. Associated bjects which represent the values of the variables of a m th dare 
stored in a list as property "variables" of a user-defined frame during performance of the method. Frames are 

55 discussed in greater detail bel w and in Appendix A. 
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Procedure 

Th structure f procedure 4802 is shown in Figure 49. 
Procedure 4802 includes list 4902 of objects 4902A-4902E. List 4902 is not a member of class "List", but is 

5 instead an integral part of procedure 4802. In other words, list 4902 is not a property or item of procedure 4802 
and no feature is provided which permits list 4902 to be treated as a member of class "List". In one embodiment 
of the present invention, class "Procedure" is an implementation subclass of class "List" but is not an interface 
subclass of class "List". Therefore, the features that are defined by class "List" are not inherited by class "Pro- 
cedure" but the methods defined by class "List" can be used by a procedure to create and access list 4902. 

10 Objects 4902A-4902E are executed objects, i.e., members of mix-in class "Executed". Procedure 4802 is 

performed by executing objects 4902A-4902E sequentially, i.e., in the order of object 4902A, object 4902B, 
object 4902C, object 4902D and object 4902E. During execution of procedure 4802, a predefined frame records 
and maintains the dynamic state of a performance of procedure 4802, including which of objects 4902A4902E 
is executing. Predefined frames are discussed below and in detail in Appendix B. 

15 

Citation 

A citation is an object which identifies a series of objects each of which is backward- or forward-compatible 
with the others. A citation further identifies a particular object in the series and the process, or the authority 
20 of the process, that created the particular object. As discussed briefly above, classes are cited objects. There- 
fore, citations are used to identify series of classes which are backward- and forward-compatible with one an- 
other. Backward- and forward-compatibility are discussed In greater detail below and in Appendix A. 

It should be noted that objects whose citations identify the objects as forward- or backward compatible 
with one another are not necessarily forward- or backward-compatible. For example, two class definition ob- 
25 jects which are identified by their respective citations as compatible are merely intended to be compatible. 

Citation 5000 (Figure 50) is a member of class "Citation". The properties of citation 5000 include properties 
"title", "majorEdition", "minorEdition" and "author". Property "title" of citation 5000 is identifier 5008. Identifier 
5008 is therefore the title of citation 5000. The title of a citation references the series that the citation repre- 
sents. The title of a citation is interpreted relative to the citation's authority. In other words, two citations of 
30 different authorities can use equivalent titles. The two citations are distinguished from one another by the dif- 
ferent authorities. The authority of a citation is identified by property "author" which is discussed below. 

Properties "majorEdition"and "minorEdition" are integers 5004 and 5006, respectively. Integers 5004 and 
5006 are therefore the major and minor editions, respectively, of citation 5000. The relation between two ob- 
jects in a series is determined by the relative major and minor editions of the objects. For example, objects 
35 5102 and 51 04 (Figure 51) are cited by citations 5106 and 51 08, respectively. Integers 5110 and 5112 represent 
the major and minor editions, respectively, of citation 5106. Integers 5114 and 5116 represent the major and 
minor editions, respectively, of citation 5108. 

If integer 5110, the major edition of citation 5106, is greater than integer 5114, the major edition of citation 
5108, then object 5102 was created subsequent to the creation of object 5104 and is backward-compatible 
40 with object 51 04. If object 51 02 is backward-compatible with object 51 04, object 51 04 is forward-compatibl 
with object 5102. Conversely, if integer 5110 is less than integer 5114, object 5104 was created subsequent 
to the creation of object 5102 and is backward-compatible with object 5102. 

If integers 5110and5114areequal,the relative values of integers 51 1 2 ad 51 1 6, respectively representing 
the minor editions of objects 5102 and 5104, determine the relation between objects 5102 and 5104. For ex- 
45 ample, if integer 5 1 1 2 is greater than integer 51 1 6, object 51 02 was created subsequent to the creation of object 
5104 and is backward-compatible with object 5104. Conversely, if integer 5112 is less than integer5116, object 
5104 was created subsequent to the creation of object 5102 and is backward-compatible with object 5102. 

Property "author* is telename 5002 (Figure 50). Telename 5002 is therefore the author of citation 5000. 
Telename 5002 is the name of the process creating the object identified by citation 5000. All objects of a single 
so series are created by processes of a single authority. 

While a more precise definition of "forward-" and "backward-compatibility" is given in Appendix A, the fol- 
lowing example illustrates the meaning and utility of such concepts. As defined in Appendix A, a member of 
class "Integer", i.e., an integer, can perform a number of arithmetic operati ns, including "add", "subtract", "mul- 
tiply" and "divide". Property "citation" of class "Integer* is a first citation identifying class "Integ r". In imple- 
55 menting the set of computer instructions described h rein and in defining new classes and new features in 
using the set of computer instructions described herein, a pi th ra of f atures are designed in reliance of mem- 
bers f class "Integ r" comporting with the description of class "Integer" as described in Appendix A. 

Suppose in a subsequent version of the set of computer instructions described herein that a second class 
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"Integ r" is defined to provide an operation "randomize 0 to generate random numbers. The former class "In- 
teger" is called the first class "Integer". Property "citation" of th s cond class "Integer" is a second citation. 
Suppose further that there are no oth r differences betwe n the first class "Integer" and the second class "In- 
teger" and that any feature requested of a member of the first class "Integer" is satisfied by a member of the 
5 second class "Integer". Thus, the features which are designed in reliance of integers comporting with the de- 
scription of the first class "Integer", function properly given integers of the second class "Integer". The second 
class "Integer" is therefore backward-compatible with the first class "Integer". Conversely, the first class "In- 
teger" is forward-compatible with the second class "Integer". 

Property "title" of both the first and the second citations is equal and references either class "Integer". How- 
to ever, the major and minor editions of the first and second citations reflect the forward- and backward-compa- 
tibility relation between the first and second classes "Integer". Permitting backward- and forward-compatible 
objects to co-exist within the network permits objects created by earlier versions of the set of computer in- 
structions described herein to travel to and operate within engines implementing a later version of the set of 
computer instructions described herein. It is clear from the foregoing that a class is both forward- and back- 
15 ward-compatible with itself. While the illustrative example above demonstrates forward- and backward-com- 
patibility in the context of a predefined class, user-defined classes are typically changed more frequently than 
predefined classes. Therefore, providing forforward- and backward-compatibility among classes is particularly 
important in the context of user-defined classes. 

Thus, classes are made part of the disclosed instruction set and are therefore portable and can travel with 
20 an agent from a first computer system to a second computer system. 

Interpreted Instruction Set 

As discussed above, three aspects of the present invention make computer processes particularly mobile 

25 and general. The first is that the computer instruction set of the present invention is implemented homogene- 
ously in a homogeneous or heterogeneous network. Secondly, classes are objects of the disclosed computer 
instruction set so that the instruction set is both extensible and mobile. That is, classes, which are not defined ■ 
on remote computer systems, are transported with mobile computer processes to such remote computer sys- 
tems. The following discussion concerns the third aspect making the computer instruction set particularly gen- 

30 eral and mobile; the computer instructions of the disclosed computer instruction set are interpreted. 

Most computer processes are first written in a human-readable source code which is then compiled into 
object code and linked into machine code, which is entirely unintelligible to human beings. The primary advan- 
tage of translating the source code into machine code is that the translation need occur only once as the ma- 
chine code can be executed by a computer system's CPU any number of times without recompilation of the ; 

35 source code. However, two computer systems of a heterogeneous network can have incompatible CPUs which 
do not both execute identical machine code instructions. It is therefore preferred that agents, traveling from 
a first computer system to a second computer system, be represented in a standardized instruction set that is 
not specific to either the first or the second computer system. 

Since the advantages of one-time compilation of source code are eliminated by the heterogeneity of the 

40 network, the disclosed computer instruction set is interpreted. The term "interpreted" is used herein as it is 
understood in the art; a computer instruction in a series of computer instructions is read, translated into ma- 
chine code, and executed by an engine before the next computer instruction in the series is read. 

Interpreting, rather than compiling, instructions of the disclosed instruction set provides greater generality. 
A first agent can travel from a first computer system to a second computer system and meet with a second 

45 agent there which gives to the first agent a procedure. The first agent can then perform the procedure which 
the first agent was not originally designed to perform. 

The following discusses the interpretation of the disclosed computer instructions. The discussion focuses 
on procedures and execution of items of procedures, the items being individual computer instructions. 

so Execution of a Procedure 

A procedure is perform d by issuing an instruction requesting that the procedure p rform operation "do". 
Other op rations which cause performance f a procedure are discussed below and in Appendix A. Perfor- 
mance of operation "do" as defined for class "Procedure" is shown by logic flow diagram 5200 (Figure 52A) 
55 and is repres nted by a predefined frame 5250 (Figure 52B). Predefined frame 5250 includes properties "pos- 
ition" and "procedure", which are, respectively, integer 5252 and procedure 4802. Predefined frames are dis- 
cussed in greater detail in Appendix B. Predefined frame 5250 records the dynamic state of operation "do" as 
performed by procedure 4802 (Figure 49). 
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Procedure 5406 (Figure 54) is property "procedure" of user-d fined frame 5304, which is a property in- 
herited from superclass "Procedure Frame 0 . Procedure 5406 is property "procedure" of the method object 
whose dynamic state user-defined frame 5304 records. For example, if user-defined f ram 5304 records the 
dynamic state of method object 4800 (Figure 48), procedures 4802 and 5406 are the same procedure. 

5 Integer 5408 is property "position" of user-defined frame 5304 inherited from superclass "Procedure 

Frame". Integer 5408 identifies the position within procedure 5406 of the item of procedure 5406 which is cur- 
rently being executed. For example, if the second item of procedure 5406 is the item of procedure 5406 whose 
execution has begun and has not yet finished, the value of integer 5408 is two. 

User-defined frame 5304 includes two additional properties, namely, properties "stack" and "variables". 

10 Stack 541 0 is property "stack" of user-defined frame 5304 and is the stack of user-defined frame 5304. At the 
beginning of execution of procedure 5406, stack 5410 contains the arguments consumed by performance of 
the feature or conversion whose dynamic state is recorded by user-defined frame 5304. After execution of pro- 
cedure 5406, stack 5410 contains the result, if any, produced by performance of the feature or conversion. 
List 5412 is property "variables" of user-defined frame 5304. The items of list 5412, e.g. object 54121, are 

15 the variables of the frame. Variables record the dynamic state of user-defined frame 5304 as procedure 5406 
is performed. Variables which are items of list 5412 (Figure 54) are referenced by like-positioned items of prop- 
erty "variables" of the method object whose dynamic state is recorded by user-defined frame 5304. For ex- 
ample, if user-defined frame 5304 records the dynamic state of method object 4800 (Figure 48), identifier 4804I 
which is at position one within list 4804 references object 54121 (Figure 54) which is at position one within list 

20 5412. 

Thus, user-defined frame 5304 records the dynamic state of a user-defined feature or conversion by re- 
cording (I) the responder of the feature or conversion, (ii) the procedure implementing the feature or conversion, 
(Hi) the position within the procedure of the currently executing instruction, (iv) the stack containing the argu- 
ments or result of the feature or conversion and (v) the variables which record the dynamic state of user-defined 
25 frame 5304. 

Execution of Executed Objects 

As discussed above, the performance of a procedure is the sequential execution of the items of the pro- 
30 cedure. In general, the execution of an executed object, i.e., an object which inherits from mix-in class "Exe- 
cuted", results in a reference to the object being pushed on to the stack, e.g., stack 5410, of the frame repre- 
senting the execution state of the procedure. However, the execution of identifiers, modifiers and selectors 
are except tons to this general rule. 

35 Identifiers 

Unless executed in the presence of a modifier indicating otherwise, an executed identifier is presumed 
to reference a feature and therefore invokes an operation or queries an attribute. Execution of an identifier 
within a first procedure causes the feature referenced by the identifier to be performed, thereby causing the 

40 performance of a second procedure. The second procedure is the procedure of the method object which im- 
plements the operation or attribute referenced by the identifier. The execution of an identifier which references 
a feature is shown by logic flow diagram 5500 (Figure 55). 

Logic flow diagram 5500 is discussed in the context of Figures 56A-56C. Stack 5302 (Figure 56A) is the 
execution thread, i.e., property "frames", of process 5300. User-defined frame 5304 is the current frame. The 

45 current frame is the frame containing the procedure, i.e., procedure 5406, whose items are currently being 
executed by an engine. In other words, the next executed object, which an engine executes in the interpretation 
of process 5300, is retrieved from the procedure of user-defined frame 5304. 

Procedure 5406 is property "procedure" of user-defined frame 5304. Integer 5408 is property "position" 
of user-defined frame 5304 and indicates the position within procedure 5406 of the item whose execution was 

so most recently begun by the engine processing process 5300. 

The execution of an identifier occurs when the item of procedure 5406 at the position indicated by integer 
5408 is an identifier. In this exampl , th identifier references an peration. The operation referenced by the 
identifier is sometimes called "the subject operation" in th context of Figures 56A-56C and 55. The execution 
of the identifier is shown by logic flow diagram 5500 (Figure 55). 

55 Th requester's stack, i.e. stack 541 0, is produced by querying attribute "stack" of user-defined frame 5304 

in step 5502. Since perf rmance of procedure 5405 (Figure 56A) of us r-defined frame 5304 is requesting 
execution of the identifier at the position within procedure 5406 indicated by integer 5408, property "responder" 
of user-defined frame 5304, which is the current frame, is the requester of the operation referenced by the 
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identifier. In the context of Figure 56A, the responder is process 5300. Stack 5410 is therefore the "requester's 
stack". 

Processing transfers from st p 5502 (Figure 55) to a stack empty test step 5504. At the time the id ntif ier 
is executed, the object at the top of stack 5410 is the responder of the subject operation. In stack empty test 
5 step 5504, the engine interpreting process 5300 determines whether stack 5410 is empty. If stack 5410 is de- 
termined to be empty, processing transfers from stack empty test step 5504 to terminal step 5506 in which an 
exception of the class "Responder Missing" is thrown and the subject operation fails. Otherwise, if stack 5410 
is not empty, processing transfers from stack empty test to step 5508 in which the object (not shown) at th 
top of stack 5410 is popped from stack 5410. The object popped from stack 5410 is the intended responder 
10 of the subject operation of the executing identifier and is sometimes referred to as "the responding object" in 
the context of Figures 56A-56C and 55. 

It should be noted that the subject operation is user-defined and therefore represented by a user-defined 
frame. Features which are predefined are represented directly in an engine. In other words, the instructions 
which form a predefined operation are included in the instructions which form the computer process that is an 

15 engine. If the executed identifier references a predefined operation, the instructions which define the operation 
within the engine are located and performed. One implementation of an engine of one embodiment of the pres- 
ent invention, including instructions which define the predefined operations described herein and in Appendix 
A, is disclosed in the software of Appendix G which is incorporated herein in its entirety by reference. 

Processing transfers from 5508 to step 5510. In step 5510, the operation definition defining the subject 

20 operation is retrieved. The selection of the operation definition and the associated method object is discussed 
below in detail. Processing transfers from step 5510 to access test step 5512. In access test step 5512 the 
access of the subject operation is verified. Property "isPublic", e.g., boolean 4404 (Figure 44), is retrieved from 
the operation definition. If the access of the subject operation is not "public", i.e., if property "isPublic" is "false" 
and the responding object is not property "responder- (not shown) of user-defined frame 5304, processing 

25 transfers from access test step 5512 to terminal step 5514. 

In terminal step 5514, an exception of class "Feature Unavailable" is thrown and the subject operation fails. 
Otherwise, if property "isPublic" is "true" or the responding object is property "responder" of user-defined 
frame 5304, the access of the subject operation is acceptable and processing transfers from access test step 
5512 to number of arguments test step 5516. 

so in number of arguments test step 5516, property "arguments" of the operation definition is produced by 

querying attribute "arguments" of the operation definition. The number of items in the list of property "argu- 
ments" is compared to the number of objects on stack 5410. If property "arguments" defines a number of ar- 
guments that is greater than the number of objects present on stack 5410, processing transfers from number 
of arguments test step 5516 to terminal step 5518. In terminal step 551 8, an exception of class "Argument Miss- 

35 ing" is thrown, causing the subject operation to fail. 

It should be noted that any exception thrown by execution of the identifier which references the subject 
operation, e.g., in either terminal step 5506 or terminal step 5514, causes the subject operation to fail, throwing 
the same exception. 

If stack 5410 contains at least as many objects as there are arguments as indicated by property "argu- 
ments" of the operation definition retrieved in step 551 0, processing transfers from number of arguments test 
step 5516 to classes of arguments test step 5520. In classes of arguments test step 5520, the engine inter- 
preting process 5300 determines whether each object on stack 541 0 in the position of an argument satisfies 
the corresponding constraint within the list that is property "arguments" of the operation definition retrieved 
in step 551 0. For example, constraint 45021 of list 4502 (Figure 45), which is property "arguments" of operation 
definition 4500. corresponds to the object at the top of stack 5410. The structure of a constraint is discussed 
in greater detail above and in Appendix A. 

As discussed above in greater detail, a constraint restricts an object by specifying (i) a class of which the 
object must be a member, (ii) whether the object must also be an instance of the class specified, and (iii) wheth- 
era nil satisfies the constraint irrespective of the class specified. Each object on stack 5410 which corresponds 
to a constraint is examined to determine whether the object satisfies the constraint in classes of arguments 
test step 5520. If any of the objects on stack 5410 does not satisfy the corresponding constraint of property 
"arguments" of the operation definition, processing transfers from classes f arguments test step 5520 to ter- 
minal step 5522 in which an exception of class "Argument Invalid" is thrown. 

Conversely, if each of th obj cts on stack 541 0 satisfies the corresponding constraint, processing trans- 
fers from class of arguments test step 5520 to step 5524. In step 5524, the method bject defining the imple- 
mentation of th subject operation in the context of the responding bj ct is selected. The method object is 
selected from the classes of which the resp nding object is a member as discuss d in great r detail b low. 
Processing transfers from step 5524 to step 5526 in which a new user-defined frame 5602 (Figure 56B) 
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is created. Responding object 5604 is mad property "responded of new user-defined frame 5602. Property 
°proc dure" of the method object selected in step 5524 is procedure 5606 and is made property "procedure" 
of new user-defined frame 5602. Property °p sition" of user-defined frame 5602 is initialized to be an integer 
5608 whose value is zero. And property "stack" is initialized to an empty stack 5610. 
5 Once new user-defined frame 5602 is created, processing transfers from step 5526 to step 5528 in which 

objects are moved from stack 5410 of user-defined frame 5304 to stack 5610 of user-defined frame 5602. 
Objects are moved from slack 5410 to stack 5610 such that the order of objects is preserved. In other wortJs, 
the topmost argument on stack 5410 is at the top of stack 5610, and the bottommost argument on stack 5410 
is at the bottom of stack 5610. Each object is moved according to property "passage" of the corresponding 
10 constraint of property "arguments" of the retrieved operation definition. 

If property "passage" is "byRef , the reference to the object is popped from stack 5410 and is pushed on 
to stack 5610. Thus, procedure 5606 of new user-defined frame 5602 has the same access to the argument 
as does procedure 5406 of requesting user-defined frame 5304. 

If property "passage" is "byProtectedRef", the reference to the object is popped from stack 5410, is made 
15 a protected reference, and is pushed on to stack 561 0. Thus, procedure 5606 of new user-defined frame 5602 
cannot alter the argument and the argument is therefore "readonly". 

If property "passage" is "byUnpnotectedRef", whether the reference to the argument on stack 5410 of re- 
questing user-defined frame 5304 is protected is determined. Such a determination is made by querying at- 
tribute "isProtected" which is described more completely in Appendix A. If the reference is protected, an ex- 
20 ception of class "Reference Protected" is thrown. Otherwise, the reference is popped from stack 5410 and is 
pushed on to stack 5610. Thus, procedure 5606 of new user-defined frame 5602 Is provided access to alter 
the argument passed by unprotected reference. 

If property "passage" is "byCopy", a copy is made of the object found on stack 5410 and an unprotected 
reference to the copy is pushed on to stack 5610 of new user-defined frame 5602. Thus, procedure 5606 is 
25 given unrestricted access to a copy of the argument, which is passed by copy, but has no access to the argu- 
ment itself. 

Thus, new user-defined frame 5602 is complete and represents the dynamic state of the subject operation ' 
immediately preceding performance of the subject operation. Processing transfers from step 5528 (Figure 55) 
to step 5530 in which new user-defined frame 5602 is included in the execution state of process 5300 by being 
30 pushed on to stack 5302 (Figure 56C). Thus, stack 5410 and the method object whose property "procedure" 
is procedure 5406 are no longer the current stack and current method, respectively. Stack 5610 is the current } 
stack and the method object whose property "procedure" is procedure 5606 is the current method. Processing 
transfers from step 5530 (Figure 55) to step 5532. In step 5532, procedure 5606 (Figure 56C) of user-defined 
frame 5602 is performed. 

35 As performance of procedure 5406 executes an identifier which invokes performance of the subject op- 

eration and the creation of user-defined frame 5602, performance of procedure 5606 of user-defined frame 
5602 can execute identifiers which invoke further operations thereby creating further frames which are sub- 
sequently pushed on to stack 5302 and whose procedures are subsequently performed. Thus, the execution 
state of process 5300 is represented by one or more frames on stack 5302, which is property "frames" of proc- 

40 ess 5300 representing a thread of execution. 

After performance of procedure 5606, user-defined frame 5602 represents the dynamic state of the sub- 
ject operation immediately following performance of the operation. Stack 5610 of user-defined frame 5602 con- 
tains the result, if any, produced by performance of the subject operation. Processing transfers from step 5532 
(Figure 55) to step 5534 in which property "result" of the operation definition defining the subject operation is 

45 produced by querying attribute "result" of the operation definition. Processing transfers from step 5534 to result 
test step 5536, in which the membership of property "result" in class "Constraint" is determined. In other words, 
property "result" is verified to be a constraint and not a nil. If property "result" is a constraint and not a nil, th 
subject operation produces a result and processing transfers from result test step 5536 to a stack empty test 
step 5538. 

so In stack empty test step 5538, the engine interpreting process 5300 (Figure 56C) determines whether an 

object is present on stack 5610. If stack 5610 is empty, processing transfers from stack empty test step 5538 
(Figure 55) to terminal step 5540. In terminal step 5540, an exception of class "Result Missing" is thrown. If 
stack 561 0 (Figure 56C) contains an obj ct, processing transfers from stack empty test step 5538 (Figure 55) 
to class of result test step 5542. In class of result test step 5542, the engine interpreting process 5300 (Figure 

55 56C) determines whether the object on stack 561 0 satisfies the constraint that is property "result" of th p- 
eration definition. If the object does not satisfy the constraint processing transfers from class of result test 
step 5542 (Figure 55) to terminal step 5544. In terminal step 5544, an exception of class "Result Invalid" is 
thrown. If the object satisfies the constraint, processing transfers from class of result test step 5542 to step 
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5546. 

In step 5546, the object is moved from stack 561 0 (Figure 56C) of user-defined frame 5602 to stack 5410 
of user-defined frame 5304 according to property "passage" of the operation definition as described above. 
Processing transfers from step 5546 (Figure 55B) to step 5548. 

If, in result test step 5536, property "result" is nil, processing transfers directly to step 5548. In step 5548, 
new user-defined frame 5602 is popped from stack 5302 (Figure 56B) and discarded (Figure 56A) . Thus, stack 
5410 and the method object whose property "procedure" is procedure 5406 are again the current stack and 
the current method, respectively. Processing transfers from step 5548 (Figure 55B) to step 5550 in which exe- 
cution of procedure 5406 is continued by incrementing integer 5408 and executing the item of procedure 5406 
at the position indicated by integer 5408. Thus, execution of an identifier which references an operation causes 
performance of the operation. 

Operation Definition and Method Selection 

As discussed above, an operation definition and a method object, which together define the subject op- 
eration, are selected in steps 5510 and 5524, respectively (Figure 55A). The selection of the operation defini- 
tion and method are described in the context of the embodiment of the present invention described above with 
respect to Figure41B. In that embodiment, class object4102 is formed by replicating properties "citation", "in- 
terface" and "implementation" of class definition 4100. The selected operation definition is selected from an 
interface object, and the selected method object is selected from an implementation object The operation def- 
inition and method object are each selected according to logic flow diagram 5700 (Figure 57). 

The operation definition and method object, which are appropriate, depend on the class of which the re- 
sponding object is an instance. The responding object is examined to determine whether the responding object 
is a class object, i.e., is a member of class "Class" in a class test step 5702. If the responding object is a class 
object, processing transfers from class test step 5702 to a class lookup step 5704. In class lookup step 5704, 
property "classFeatures" of the responding object and the interface superclasses of the responding object are 
searched as discussed below. The lexicon of class features, i.e., property "classFeatures", is searched for a 
key which matches the identifier of the subject operation, i.e., the executing identifier. Additionally, in class 
lookup step 5704, property "classMethods" of the responding object and the implementation superclasses of 
the responding object are searched, as discussed below, for a method object associated with the executing 
identifier. 

Processing transfers from class lookup step 5704 to a test step 5706 in which the engine interpreting the 
current process, e.g., process 5300 (Figure 56A), determines whether an operation definition and a method 
object are found in class lookup step 5704. If an operation definition and a method object defining the subject 
operation are found, processing transfers from test step 5706 to terminal step 5708 where the selection process 
terminates. Otherwise, processing transfers from test step 5706 to instance lookup step 5710. Additionally, if 
the responding object is not a class object, i.e., is not a member of class "Class", processing transfers directly 
from class test step 5702 to instance lookup step 5710. 

In instance lookup step 5710, property "instanceFeatures" of the interface object of the class of which the 
responding object is an instance and of the interface objects of the interface superclasses of that class are 
searched for a feature definition associated with the executing identifier. Also in instance lookup step 5710, 
property "instanceMethods" of the implementation of the class of which the responding object is an instance 
and of the implementations of the implementation superclasses of that class are searched fora method object 
associated with the executing identifier. The order in which superclasses are searched is discussed below. 

It should be noted that if the responding object is a class object, a class method can only implement a 
class feature and an instance method can only implement an instance feature. 

Processing transfers from instance lookup step 5710 to a second test step 5712 in which the engine de- 
termines whether an operation definition and a method object are found in instance lookup step 5710. If an 
operation definition and method object identified by the executing identifier are found, processing transfers 
from second test step 571 2 to terminal step 5716. In terminal step 571 6, the selection process terminates sue- 
cessfully. Otherwise, processing transfers from second test step 5712 to terminal step 5714. In terminal step 
5714, an exception of class "Feature Unavailable" is thrown. 

P rtions of th predefined hi rarchy, which is disclosed in Appendix A which discussion is incorporated 
herein in its entirety by reference, are shown in Figures 58A and 58B to illustrat the order in which various 
classes are searched for appropriat op ration definitions and method bjects.Whil Figure 58Aand58B show 
portions of the predefined interface hierarchy, the method by which the impl mentati n hi rarchy is searched 
is as described below with respect to the searching f the int rface hierarchy. 

Hierarchy graph 5800 (Figure 58A) shows class object 5802 representing class -List". Class "List" inherits 
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from mix-in superclass "Ordered" and flavor superclass "Collection 0 represent d by class objects 5804 and 
5806, respectively. Class "Collection" inherits from superclass "Object" represented by class object 5808. 
Class "Object" inherits from mix-in superclass "Referenced" represented by class bject 581 0. In Figures 58A 
and 58B, (t) double lines are drawn between flavor classes and subclasses of the flavor classes, (ii) singl 
5 solid lines are drawn between mix-in classes and subclasses of the mix-in classes, and (iii) a dashed line is 
drawn between a class and an instance of the class. As discussed above, the last item of property "superclass- 
es" of either an interface object or an implementation object must not identify a mix-in class. The reason for 
this is discussed below. 

Suppose for illustration purposes that the responding object in the context of logic flow diagram 5700 (Fig- 
to ure 57) is class object 5802 (Figure 58A) representing class "List". In class lookup step 5704 (Figure 57), prop- 
erty "classFeatures" of the interface object, which is property "interface" of class object 5802, is searched for 
an association whose key is the executing identifier. If such an association is found, the feature definition as- 
sociated with the identifier is an operation definition which defines the interface of the subject operation and 
is selected and the search for an operation definition concludes. 
15 If, however, no such association is found, the interface object of the first superclass of class "List", namely, 

class "Ordered" is searched in the same manner for an appropriate operation definition. If no appropriately iden- 
tified operation definition is found, the superclasses of class "Ordered" are searched in a depth-first walk of 
the interface hierarchy. Since class "Ordered" has no superclasses, the next item of property "superclasses" 
of the interface object of class "List", i.e., class "Collection", is searched as described above. Since the last 
20 superclass searched is not a mix-in class, every mix-in superclass is searched before the flavor superclass is 
searched. 

Thus, in the manner described above with respect to class "List", the remainder of the class objects of Fig- 
ure 58A are searched in the following order class object 5808 representing class "Object" and class object 
5810 representing class "Referenced". 

25 The search for an appropriate method object defining the implementation of the subject operation is as 

described above for the search for an appropriate operation definition with two exceptions. First, property 
"class Methods 0 of the implementation object of a class is searched for an appropriately identified method ob- < 
ject Second, the implementation superclasses, rather than the interface superclasses, of class "List" are 
searched for an appropriately identified method object 

30 The importance of the single flavor superclass being the last superclass searched is apparent if one con- . 

siders the following hypothetical example. Suppose, for example, that class object 5806, which represents fla- 
vor "Collection", and class objects representing superclasses of class "Collection" are searched before search- 
ing class object 5804, which represents mix-in class "Ordered". Suppose further than class object 5808, which 
represents class "Object", defines one or more features which are adapted by class "Ordered", i.e., whose " 

35 methods are supplied by class object 5804. Since class object 5808, in this hypothetical example, will always 
be searched before class object 5804, the method for any feature defined by class object 5808 will always be 
found in class object 5808. It would therefore be impossible for class object 5804 to adapt any feature defined 
by class object 5808. Therefore, the flavor superclass of a flavor is always the last superclass of that flavor 
that is searched for an operation definition or method. 

40 Continuing in the illustrative example in which the responding object in the context of logic flow diagram 

5700 (Figure 57) is class object 5802 (Figures 58A and 58B) representing class "List", hierarchy graph 5850 
(Figure 58B) shows the classes searched in instance lookup step 571 0 (Figure 57). The search for an operation 
definition and method object for an instance feature of class object 5802 (Figure 58B) differs from the search 
for an operation definition and method object for a class feature as described above in two ways. First property 

45 "instanceFeatures" of the interface object of a class is searched for an appropriately identified operation def- 
inition, and property "instanceMethods" of the implementation object of a class is searched for an appropriately 
identified method object Second, the classes of which the responding object, Le., class object 5802, is a mem- 
ber are searched. 

The manner in which the classes are searched is equivalent to that described above and is not repeated 
so here. The following classes are searched in the following order until an appropriate operation definition and 
method object are found or until all classes which follow have been searched: (0 class object 581 2 representing 
class "Class" of which class object 5802 is an instanc ; (ii) class object 581 6 representing class "Interchanged", 
a mix-in superclass of class "Class"; (iii) class object 581 8 representing class "Unchanged", a mix-in superclass 
of mix-in class "Interchanged" and therefore of class "Class"; (iv) class object 5814 representing class "Cited", 
55 a mix-in superclass of class "Class"; (v) class object 5808 repres nting class "Object", a flavor superclass of 
class "Class"; and (vi) class object 581 0 representing class "Referenced", a mix-in superclass of class "Object". 

If no operation d finition or no method obj ct associated with the executing identifier is found ins arching 
the classes of Figures 58A and 58B, th operation is not defined for the responding object and an exc ption 
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of class "Feature Undefined" is thrown. 

As described abov t if the responding object is not a class, class lookup step 5704 (Figure 57) is skipp d. 
For exampl f if the responding obj ct is list 5802A which is an instance of class "List", the classes shown in 
hierarchy graph 5800 (Figure 58A) are searched in instance lookup step 5712 (Figure 57) as described above. 

In one embodiment of the present invention, the interface and implementation hierarchies are independent. 
In other words, an interface superclass of a class is not necessarily an implementation superclass of the class, 
and an implementation superclass of a class is not necessarily an interface superclass of the class. An engine 
ensures that no feature definition is without an implementation, in such an embodiment, during performance 
of operation "makeClasses". Operation "makeCiasses" fails, throwing an exception of class "Class Exception", 
upon the following condition: the class defined is not abstract, and the class defined does not define, or inherit 
from implementation superclasses, a method which implements a defined feature. Thus, a feature defined in 
the interface hierarchy is always implemented by a method found in the implementation hierarchy. 

Thus, an appropriate operation definition and method object for the subject operation are found by search- 
ing the class hierarchy as discussed above or an exception is thrown. 

Escalation 

As discussed above, a class which inherits a feature from a superclass can supersede the implementation 
of the feature by providing a new implementation for the feature. However, the new implementation may need 
to use the implementation provided by the superclass. An object is directed to perform a feature as implement- 
ed by a particular one or by any one of the immediate superclasses of the current class by escalating the fea- 
ture. As described more completely in Appendix A, the current class is the class which provides the currently 
executing method. 

A feature is escalated by executing a qualified identifier which references the feature to be escalated or 
by executing an "escalate" selector. Aqualif ied identifier includes property "qualifier" which identifies the class 
which is to provide the implementation of the feature. If a feature is escalated by execution of an "escalate" 
selector, any immediate implementation superclass can provide the implementation of the feature. 

It should be noted that no attribute is defined which provides access to property "qualifier" of a qualified 
identifier. Property "qualifier" of a qualified identifier is set when the qualified identifier is created and remains 
unaltered until the qualified identifier is destroyed. Escalation of a feature is discussed further in Appendix A. 

Escalation plays a particularly important role in initializing objects. Appendix A includes a description of 
an initialization for each predefined class of the present invention. The initialization of an object is shown by 
logic flow diagram 5900 (Figure 59) which is discussed in the illustrative context of the initialization of a list, 
i.e. an instance of class "List". Operation "initialize" is escalated for each immediate implementation superclass 
of class "List". As discussed above, hierarchy diagram 5800 (Figure 58A) represents the interface superclasses 
of class "List". Hierarchy diagram 5800 also accurately represents the implementation superclasses of class 
"List". 

Operation "initialize", as defined by the class of which the new list is an instance, i.e. class "List", is per- 
formed in step 5902. Performance of operation "initialize" consumes zero or more arguments from the current 
stack. Processing transfers from step 5902 to step 5904. In step 5904, property "superclasses" of the imple- 
mentation object of class "List" is produced by querying attribute "superclasses" of the implementation object. 
As described above, property "superclasses" of an implementation object is a list of identifiers which reference 
classes. Processing transfers from step 5904 to for each superclass step 5906. 

For each superclass step 5906 and next step 591 0 define a loop in which each superclass of property "su- 
perclasses" produced above is processed in an escalate step 5908. Thus, for each superclass, processing 
transfers from for each superclass step 5906 to escalate step 5908. In escalate step 5908, the superclass is 
directed to perform operation "initialize", according to logic flow diagram 5900. Thus, logic flow diagram 5900 
is performed recursively in a depth-first walk of the implementation hierarchy. For example, the first immediate 
superclass, to which "initialize" is escalated in escalate step 5908, (i) performs "initialize" in step 5902, (ii) pro- 
duces immediate implementation superclasses of the superclass in step 5904 and (Hi) escalates "initialize" to 
each superclass of the superclass in the loop defined by for each superclass step 5906 and next step 5910. 

Processing transfers from escalate step 5908 through n xt step 5910 to for each superclass step 5906. 
Thus, initialization is escalated to each immediate implem ntation superclass in the order found in the list that 
is property "superclasses". Each performance of operation "initializ " by a superclass of class "List" consumes 
zero or more arguments from the current stack and escalates the initialization to the immediate implementati n 
sup rclassesofth superclass. 

Once each immediate implementation superclass of class "List" has performed operation "initialize" ac- 
cording to the loop of for ach superclass step 5906 and next step 5910, processing transfers from for each 



62 



EP 0 634 719 A2 

superclass step 5906 to terminal step 5912. In terminal st p 5912, performance of op ration "initializ " as de- 
fined by class "List" completes successfully. Thus, each class of which the new list is a member p rforms op- 
eration "initialize" in the order in which classes are searched in instance lookup step 5710 (Figure 57) described 
above. 

5 

Execution of Modifiers 

The execution of an identifier is discussed at length above and in Appendix A. However, the presence of 
a modifier or the nature of the identifier can alter the execution of the identifier. For example, according to 
10 the modifier substitution rules discussed in Appendix A, if the identifier identifies an attribute, operation "ge- 
tAttribute" is performed consuming as the sole argument the executing identifier. The various modifiers and 
the effects on the execution of an identifier are discussed in Appendix A and such discussion is hereby incor- 
porated by reference. 

is Execution of Selectors 

A selector is a primitive whose execution causes a special action. While each selector is discussed in Ap- 
pendix A, several selectors are discussed herein. For example, selectors "break", "continue" and "succeed" 
are discussed below in the context of performing procedures. Execution of selector "self" pushes on to the cur- 

20 rent stack a reference to the current object, i.e. the responder of the current method. In the context of Figure 
56C, the current object is object 5604 which is property "responder" of frame 5602, the current stack is stack 
5610 which is property "stack" of frame 5602, and the current method is the method object whose property 
"procedure" is procedure 5606. Execution of selector "process" pushes on to the current stack a reference t 
the current process. In Figure 56C, the current process is process 5300. If the current process is an engine 

25 place, a nil is pushed on to the current stack. 

Thus, an engine created according to the present invention executes procedures by sequential execution 
of the items of the procedures. Execution of an item of a procedure when that item is an identifier causes exe- 
cution of the feature referenced by the identifier under the circumstances described above. The dynamic stat 
of a procedure being performed is recorded in a frame. Dynamic states of methods implementing features 

30 which are user-defined are recorded in user-defined frames. A feature definition and a method object defining ' 
the interface and implementation, respectively, of the feature are selected from the classes of which the re- 
sponding object is a member. Implementations provided by superclasses of the current class are performed 
by escalating the feature. For example, operation "initialize" is recursively escalated such that the method pro- 
vided by each class of which the responder is a member is performed. Modifiers are used to alter the execution 

35 of an identifier. And selectors provide a simple means by which commonly performed complex actions are 
caused by execution of a single object. These features combine to provide a great degree of functionality and 
generality in the disclosed set of computer instructions. 

Control Constructs 

40 

As discussed above, an agent can apply sophisticated logic to determine to which place or places to travel 
and with which agent or agents to meet. The disclosed instruction set provides a number of instructions which 
provide a large degree of generality enabling the realization of complex and sophisticated logic in procedures 
constructed of the disclosed instruction set Thefollowing control constructs which provide such a large degree 
45 of generality are discussed: (i) resources and resource allocation features provide processes with the ability 
to obtain and maintain shared or exclusive control of a resource during performance of a procedure; (ii) decision 
handling features enable processes to conditionally perform procedures; (Mi) exception handling features en- 
able processes to detect and take action upon the throwing of an exception; and (iv) looping features enabl 
a procedure to repeatedly perform a procedure to thereby efficiently perform repetitive tasks. 

so 

Resource and Resource Allocation Features 

As discussed above and in Appendix A, an engine processing on or more processes does so concurrently. 
For example, engine 132B (Figure 15E) concurrently processes agents 150Aand 150B. At any point during 
55 performance of a first procedure by agent 150A carried out by engine 132B, engine 132B can temporarily sus- 
pend performance of the first procedure by agent 150 A. Engine 132B is then fre to carry out performance 
fa second procedure on behalf of agent 150B. At any point during performance f the second procedure, en- 
gine 132B can temporarily suspend performance of the second procedure on behalf of agent 150B and resume 
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performance of the first procedure on b half of ag nt 150A. In this manner, engine 132B concurrently proc- 
esses agents 150A and 150B. 

As discussed in Appendix A, an engine carries out performance of most of the predefined features atom- 
ically. A feature is performed atomically if the engine refuses to suspend performance of the feature for the 
5 purpose of processing another process until the feature has completed successfully or failed. When a feature 
is performed atomically, no process but the current process can alter or manipulate resources since no other 
process will be interpreted during performance of the feature. Those predefined features which are not per- 
formed atomically are discussed in Appendix A. 

There is no mechanism for causing a user-defined feature to be performed atomically. Thus, a mechanism 
10 is needed to enable a process to obtain shared or exclusive use of a resource during performance of a user- 
defined feature or a predefined feature which is not performed atomically. A user is able to configure a process 
to obtain shared or exclusive use of a resource by use of operation "use" which is defined by class "Resource" 
and is described in detail in Appendix A. The dynamic state of a performance of operation *\jse" is recorded 
by a use frame of class "Use Frame". Use frames are discussed in Appendix B. 

15 

Conditional Execution of Executed Objects 

An executed object is executed conditionally by performance of operation "ir or operation "either". Per- 
formance of operation "ir by a responding executed object consumes a boolean object and performs the exe- 

20 cuted object if the value of the boolean object is "true." It should be noted that procedures are executed objects, 
i.e., members of mix-in class "Executed", and that the performance of a procedure is discussed above with 
respect to Figures 52Aand 52B. 

Logic flow diagram 6000 (Figure 60) shows the implementation of operation "if" as defined by mix-in class 
"Executed". In performing operation "ir, the responding executed object pops a boolean object from the current 

25 stack in step 6002. Processing transfers from step 6002 to a boolean teststep 6004, in which the boolean object 
popped in step 6002 is compared to "true". If the boolean object is "true", processing transfers from boolean 
test step 6004 to step 6006 in which the responding executed object is performed. Processing transfers from 
step 6006 to exception test step 601 0 in which the engine carrying out performance of operation "if" determines 
whether execution of the responding executed object in step 6006 threw an exception. 

30 If no exception is thrown in step 6006, processing transfers from exception test step 601 0 to terminal step 

6008. Additionally, processing transfers from boolean test step 6004 directly to terminal step 6008 if the boo- 
lean object is false". In terminal step 6008, operation "if completes successfully. If an exception is thrown in 
step 6006, processing transfers from exception test step 6010 to terminal step 6012 in which any exception 
thrown by performance of the responding executed object in step 6006 is thrown, causing operation "if to rail. 

35 The dynamic state of a performance of operation "ir is recorded by a predefined frame, i.e. a member of class 
"Predefined Frame", which is discussed above and in Appendix B. 

One of two executed objects is selected and executed by use of operation "either". An executed object 
performs operation "either" by consuming a second executed object and a boolean object and causing exe- 
cution of the responding executed object if the boolean object's value is "true" and, causing execution of the 

40 second executed object if the boolean object's value is "false." Logic flow diagram 61 00 (Figure 61) shows the 
implementation of operation "either" as defined by mix-in class "Executed". 

The responding executed object pops from the current stack a second executed object in step 6102. Proc- 
essing transfers from step 6102 to step 6104 in which the responding executed object pops from the current 
stack a boolean object. Processing transfers from step 6104 to boolean test step 6106 in which the boolean 

45 popped in step 6104 is compared to "true". If the boolean object is "true", processing transfers from boolean 
test step 6106 to step 6108 in which the responding executed object is performed. Conversely, if the value of 
the responding boolean object is "false", processing transfers from boolean step 6106 to step 6110 in which 
the second executed object is performed. Processing transfers from step 6108 or step 6110 to terminal step 
6112. In terminal step 6112, operation "either" terminates, throwing any exception thrown in step 6108 or step 

so 6 1 1 0. The dynamic state of an executed object performing operation "either" is recorded by a predefined frame. 

An executed object is selected from one or more executed objects and performed by performance of op- 
eration "selecT. Operation "select" is defined by class "Object" and is performed by an object identifying the 
particular executed object to be performed. Figures 62A and 62B show the interface f the peration Select". 
Figure 62A shows th state of predefined frame 6200 which records the dynamic state of operation "select" 

55 as performed by obj ct 6204. Predefined frame 6200 is part of th xecution state of a process (not shown) 
and is shown immediately prior to performance of operation "s lect". 

Object 6204 is the responder. Pred fined frame 6200 has n property "responded which identifies object 
6204. Instead, obj ct 6204 is identified as the responder by its position within property "procedure" of the frame 
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(not shown) immediately below the curr nt frame on the stack (not shown) that is property "frames" of the cur- 
rent process. Object 6204 is the item of that procedure (not sh wn) whose position is one less than property 
"position" of that frame. For example, the responder of user-defined frame 5602 (Figure 56C) is the item of 
procedure 5406 whose position is one less than the value of integer 5408. 

5 Stack 6202 (Figure 62A) is the current stack. On stack 6202 are a mark, whose position is indicated by 

letter "M" and which delineates the arguments of the operation, and one or more pairs of objects and associated 
executed objects. For example, stack 6202 contains from top to immediately above the mark, object 6206, exe- 
cuted object 6208, object 6210, executed object 6212, nil 6214, and executed object 6216. Objects 6206, 6210 
and nil 6214 are associated with respective executed objects 6208, 6212 and 6216. 

10 The implementation of operation "select" is shown by logic flow diagram 6300 (Figure 63). In step 6302, 

objects 6206-7616 (Figure 62A) and the mark are popped from stack 6202. Processing transfers from step 
6302 to step 6304 in which a dictionary is formed whose keys are objects 6206, 6210 and nil 6214 and whose 
associated values are respective executed objects 6208, 621 2 and 621 6. Processing transfers from step 6304 
to step 6306. In step 6306, the executed object whose associated key is equal to responding object 6204 is 

15 retrieved from the dictionary formed in step 6304. The retrieval of a value of a dictionary given a key of the 
dictionary is described in detail in Appendix A. 

Processing transfers from step 6306 to a test step 6308. In test step 6308, the engine carrying out per- 
formance of operation "select" determines whether an executed object is successfully retrieved from the dic- 
tionary. If an executed object associated with a key equal to responding object 6204 is found within the die- 

20 tionary and retrieved, processing transfers to step 6314. In step 6314, the retrieved executed object is per- 
formed. Processing transfers from step 6314 to exception test step 631 6 in which the engine determines wheth- 
er the performance of the executed object completed successfully in step 6314. 

If performance of the executed object in step 6314 fails and throws an exception, processing transfers 
from exception test step 6318 to terminal step 6320. In terminal step 6320, the exception is thrown, causing 

25 operation "select* to fail. If, on the other hand, the retrieved executed object is performed successfully in step * 
6314, processing transfers from exception test step 6318 to terminal step 6316. In terminal step 6316, oper- ' 
ation "select" completes successfully. 

In test step 6308, if no key equal to responding object 6204 is found in the dictionary formed in step 6304, 
processing transfers from test step 6308 to step 631 0. In step 6310, the executed object contained within the . 

30 dictionary whose associated key is a nil, e.g., executed object 6216 associated with nil 6214, is retrieved. Proo ; 
essing transfers from step 631 0 to a second test step 63 1 2 in which the engine determines whether an executed " 
object is successfully retrieved in step 631 0. If an executed object within the dictionary with an associated key . 
that is a nil is found and successfully retrieved, processing transfers from second test step 6312 to step 6314 :.. 
which performs the executed object as described above. 

35 if, on the other hand, no executed object is retrieved in step 631 0, no key equal to object 6204 and no key 

that is nil is found in the dictionary and processing transfers from second test step 6312 to terminal step 6316. 
As described above, in terminal step 6316, operation "select" completes successfully. Thus, if no executed 
object is associated with a key equal to the responding object or is associated with a nil, operation "select" 
completes successfully without performing any executed object in the dictionary. 

40 Figure 62B shows the state of select frame 6200 immediately following performance of operation "select" 

by responding object 6204. Performance of operation "select" produces no result as shown by empty stack 
6202 of Figure 62B. 

An executed object- is executed repeatedly so long as a condition is met by performance of operation 
"while". The dynamic state of a performance of operation "while" is recorded in a predefined frame 6402 (Figure 

45 64). Executed object 6404 is the responder of operation "while" and is the responding executed object. Exe- 
cuted object 6404 is property "procedure" of predefined frame 6402. Executed object 6406 is property "pre- 
condition" of predefined frame 6402 and is the executed object consumed as an argument as discussed below. 

Operation "white" is performed by responding executed object 6404 which consumes as an argument exe- 
cuted object 6406. Performance of operation "while" is illustrated by logic flow diagram 6500 (Figure 65). In 

so step 6502, executed object 6406 is popped from the current stack. Processing transfers from step 6502 to step 
6504, in which executed object 6406 is performed. Performance of executed object 6406 in step 6504 pushes 
ont the current stack a boolean which indicates wh ther responding xecuted object 6404 is t b p rformed. 

Processing transfers from step 6504 to exception test step 6506 in which the ngme carrying out perfor- 
mance of operation "while" determines whether performance of xecuted object 6406 throws an exception. If 

55 performance of executed object 6406 throws an exception, processing transfers from exception test step 6506 
to terminal step 6508 in which th exception is thrown by peration "while" causing operation "while* to fail. 
If, n the other hand, ex cuted object 6406 is performed successfully, processing transfers from exception 
test step 6506 to step 6510. 
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Instep 6510, a boolean is popped from the current stack. Processing transfers from step 6510 to true test 
step 6512. In true test step 6512, the boolean popped from the current stack is compared t "true". If the boo- 
lean is "true", processing transfers from true test step 6512 to step 6514 in which responding executed object 
6406 is performed. Processing transfers from step 6514 to a second exception test 6516 in which the engine 

5 determines whether performance of executed object 6404 throws an exception. 

If performance of executed object 6404 in step 6514 throws an exception, processing transfers from s c- 
ond exception test step 6516 to a continue test step 6522. In continue test step 6522, the thrown exception is 
compared to an internal exception "continue", which is thrown by execution of selector "continue" as described 
below and in Appendix A. As described below in greater detail, execution of selector "continue" terminates an 

10 iterative performance of a procedure and initiates a new iterative performance of the procedure. If the exception 
thrown in step 6514 is internal exception "continue", processing transfers from continue test step 6522 to st p 
6504, which is described above. 

Conversely, if the exception thrown in step 6514 is not internal exception "continue", processing transfers 
from continue test step 6522 to a break test step 6524. In break test step 6524, the exception thrown in step 

15 6514 is compared to an internal exception "break", which is thrown by execution of selector "break" as descri- 
bed below and in Appendix A. As described below in greater detail, execution of selector "break" terminates 
an iterative performance of a procedure without initiating a new iterative performance of the procedure. If the 
exception thrown in step 6514 is internal exception "break", processing transfers from continue test step 6522 
to terminal step 6520, in which operation "while" completes successfully as described below. 

20 Conversely, if the exception thrown in step 6514 is not internal exception "break", processing transfers 

from break test step 6524 to terminal step 6518. In terminal step 6518, the exception thrown in step 6514 is 
thrown causing operation "while" to fail. 

If, on the other hand, performance of executed object 6404 succeeds and no exception is thrown in step 
6514, processing transfers from second exception test step 6516 to step 6504 in which executed object 6406 

25 is again performed. 

Performance of steps 6504, 6506, 6510, 6512, 6514, 6516, and 6522 is repeated until performance of exe- 
cuted object 6406 produces a boolean whose value is "false" or until an exception is thrown in step 6508 or 
step 651 8. If performance of executed object 6406 produces a boolean that is "false", processing transfers 
from true test step 6512 to terminal step 6520 in which operation "while" completes successfully. Thus, pro- 
30 cedure 6406 is repeatedly performed while performance of executed object 6406 produces a "true" boolean. 

Thus, operations "if, "either", "select" and Vhile" provide the disclosed set of computer instructions sub- 
stantial decision making capabilities. 

Exception Handling Features 

35 

As discussed in greater detail in Appendix A, an executed object which performs operation "do" is thereby 
performed, and if performance of the executed object throws an exception, the exception is thrown by op r- 
ation "do", causing operation "do" to fail. The propagation of exceptions is illustrated in steps 5210 and 5212 
of logic flow diagram 5200 (Figure 52A) as discussed above. Failure of a performance of an executed object 

40 generally causes the failure of any executed object invoking, either directly or indirectly, the performance. Any 
exception which causes operation "live" of a process to fail causes destruction of the process. It is therefore 
preferred that instructions be provided which detect and prevent the propagation of exceptions. 

Af irst executed object, e.g., a procedure, invoking the performance of a second executed object is capable 
of preventing failure of the first executed object due to an exception thrown by the second executed object by 

45 "catching" any exception thrown by the second executed object. To "catch" an exception is to detect the throw- 
ing of the exception and to direct that specific action be taken in such an event. An exception which is thrown 
by the second executed object and which is caught by the first executed object does not cause the first exe- 
cuted object to fail. 

An exception thrown by performance of an executed object is caught by causing performance of the exe- 
so cuted object by use of operation "catch" in the place of operation "do". An executed object, whose performance 
is caused by operation "catch", is performed as if the executed object were performing operation "do" except 
that certain exceptions thrown by performance of the executed object do not cause operation "catch" to fail. 
In such a case, the xception is pushed on to the current stack and returned as a result 

Th interface of operation "catch" is shown by Figures 66A and 66B. Figur 66A shows the stat of catch 
55 frame 6602, which records the dynamic state f operation "catch" as defined by mix-in class "Executed", im- 
mediately prior to performance of peration "catch" by executed bject 6604. Catch frame 6602 is part of the 
execution state of a process (not shown). Executed obj ct 6604 is the responding executed object and is prop- 
erty "procedure" of catch frame 6602. Performance of operation "catch" consumes a single argument class 
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bject 6608 which is at the top of stack 6606. Stack 6606 is the current stack. Stack 6606 is property "stack" 
f the topmost user-defined frame (not shown) below catch frame 6602 on the stack (not shown) that is prop- 
erty frames" of the current process. Class object 6608 represents class "Exception" or a subclass thereof. 
The implementation of the operation "catch" is shown by logic flow diagram 6700 (Figure 67). Class object 
5 6608 is popped from stack 6606 and thereby consumed in step 6702. Processing transfers from step 6702 to 
step 6704 in which executed object 6604 is performed. Processing transfers from step 6704 to exception test 
step 6706 in which the engine carrying out performance of operation "catch" determines whether performance 
of executed object 6604 throws an exception. If performance of executed object 6604 does not throw an ex- 
ception, processing transfers from exception test step 6706 to step 6708. In step 6708, a nil is pushed on t 
10 stack 6606. Processing transfers from step 6708 to terminal step 6710 in which operation "catch" completes 
successfully. 

If execution of executed object 6604 in step 6704 fails and throws an exception, processing transfers from 

exception test step 6706 to member test step 6712. In member test step 6712, the engine checks membership 

of the exception thrown in step 6704 in the class represented by class object 6608. If the thrown exception is 
15 not a member of the class represented by class object 6608, processing transfers from member test step 6712 

to terminal step 6714. In terminal step 6714, the exception thrown in step 6704 is thrown by operation "catch" 

and operation "catch" fails. 

If the thrown exception is a member of the class represented by class object 6608, processing transfers 

from member test step 6712 to step 6716. In step 6716, the exception thrown in step 6704 is pushed on to 
20 stack 6606 and processing transfers from step 6716 to terminal step 6710. As described above, in terminal 

step 6710, operation "catch" completes successfully. Thus, the thrown exception is caught, and operation 

"catch" succeeds and does not propagate the thrown exception. 

Figure 66B shows the state of catch frame 6602 Immediately following performance of operation "catch" 

by procedure 6604. At the top of stack 6606 is exception 6610 which is the exception thrown by performance 
25 of procedure 6604 if performance of procedure 6604 failed. In such a case, exception 6610 is a member of 

the class represented by class object 6608 (Figure 66A). In place of exception 6610 (Figure 66B) on stack 6606* 

is a nil (not shown) if performance of procedure 6604 succeeded. Thus, the disclosed set of computer instruc- 

tions is provided with means for detecting and handling exceptions. 

30 Looping Features 

The disclosed computer instruction set provides means for repeatedly performing an executed object, e.g., 
a procedure, facilitating performance of repetitive tasks. Operation "while" discussed above is one example 
of a looping feature. Additionally, an executed object is performed repeatedly using operations "loop" and "re- 
35 peat". 

Operation "loop" performs an executed object indefinitely by repeatedly performing the responding exe- 
cuted object. Performance of operation "loop" by an executed object consumes no arguments and produces 
no result. Performance of operation "repeat" by an executed object consumes an integer argument and pro- 
duces no result, performing the responding executed object a number of times equal to the value of the integer 

40 argument consumed. Each performance of the responding executed object in the course of performing oper- 
ation "loop" or operation "repeat" is herein called an "iterative performance" of the executed object 

Logic flow diagram 6800 (Figure 68) shows the implementation of operation "loop" as performed by the 
responding executed object. The responding executed object is performed in step 6802. Processing transfers 
from step 6802 to exception test step 6804 in which the engine carrying out performance of operation "loop" 

45 determines whether performance of the responding executed object throws an exception. If no exception is 
thrown, i.e., if the responding executed object is performed successfully, processing transfers from exception 
test step 6804 to step 6802 in which the responding executed object is performed again. Otherwise, if perfor- 
mance of the responding executed object throws an exception, processing transfers from exception test step 
6804 to continue test step 6806. In continue test step 6806, the exception thrown by performance of the re- 

so sponding executed object in step 6802 is compared to internal exception "continue". 

Internal exceptions "continue" and "break" are thrown by execution of selectors "continue" and "break", 
respectively, which are discussed mor completely below and in Appendix A. These exceptions are called "in- 
ternal" becaus internal exceptions "continue" and "break" are detected by an engine which takes action in 
response thereto. A third internal exception, i. ., internal exception "succeed" which is thrown as a result of 

55 executing s lector "succ ed", is discussed below. Internal exceptions are not caught by operation "catch" and 
do not cause operation "live" to fail, thereby causing destruction of a process, except as described below. 

If the exception thrown by performing th executed object in step 6802 is internal exception "continu ", 
processing transfers from continue test step 6806 to step 6802 in which the responding ex cuted object is per- 
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formed again. Otherwis , if the xception thrown in not internal exception "continue", processing transfers 
from continue test step 6806 to break test step 6808. In break test step 6808, th exception thrown by per- 
forming the responding ex cuted obj ct is compared to th internal exception "break". If the exception thrown 
by performance of the executed object in step 6802 is internal exception "break", processing transfers from 
5 break test step 6808 to terminal step 6810 in which operation "loop" completes successfully. Otherwise, if the 
exception thrown is not internal exception "break", processing transfers from break test step 6808 to terminal 
step 6812 in which operation "loop"fails and the exception thrown by performance of the responding executed 
object in step 6802 is thrown by operation "loop". 

Figure 69 shows a repeat frame 6902 which records the dynamic state of a performance of operation "re- 
10 peat" by executed object 6904. Repeat frame 6902 is a part of the execution state of a process (not shown). 
Repeat frame 6902 includes properties "procedure", "repetitions", "repetitionsSoFar" and "position". Executed 
object 6904 is the responder of operation "repeat" and is property "procedure" of repeat frame 6902. Integers 
6910 and 6911 are properties "repetitionsSoFar" and "repetitions", respectively, of repeat frame 6902. Integer 
6910 represents the number of completed iterative performances of executed object 6906, and integer 6911 
is represents the total number of iterative performances specified by the consumed integer argument. 

Logic flow diagram 7000 (Figure 70) shows the implementation of operation "repeat" as performed by exe- 
cuted object 6904. In step 7002, integer 6910 is initialized to zero and integer 6911 is initialized to the valu 
of the integer consumed as an argument. Processing transfers from step 7002 to test step 7004 in which integer 
691 0 is compared to integer 691 1 . If integer 6910 is greater than or equal to integer 6911 , processing transfers 
20 from test step 7004 to terminal step 701 8 in which operation "repeat" completes successfully. Therefore, if the 
integer consumed is non-positive, performance of the operation "repeat" has no effect. Otherwise, if integer 
6910 is less than integer 6911, processing transfers from test step 7004 to step 7006 in which integer 6910 is 
incremented. Processing transfers from step 7005 to step 7006 in which an integer object whose value is that 
of integer 6910 is pushed on to the current stack. Processing transfers from step 7006 to step 7008 in which 
25 responding executed object 6904 is performed. It is up to executed object 6904 to pop the integer from the 
current stack. In other words, if performance of executed object 6904 does not pop the integer from the current 
stack, the integer remains on the current stack during performance of operation "repeat". 

Processing transfers from step 7008 to an exception test step 7010 in which the engine carrying out per- 
formance of operation "repeat" determines whether performance of responding executed object 6904 throws 
30 an exception. If no exception is thrown, processing transfers from exception test step 7010 to test step 7004. 
Conversely, if an exception is thrown, processing transfers from exception test step 7010 to continue test step 
7014 in which the exception is compared to internal exception "continue". If the exception thrown is internal 
exception "continue", processing transfers from continue test step 701 4 to test step 7004. Thus, if no exception 
is thrown in step 7008 or if the exception thrown is internal exception "continue", processing transfers to test 
35 step 7004 in which integer 6910 is again compared to integer 6911. Thus, execution of selector "continue" pre- 
maturely terminates an iterative performance of responding executed object 6904 without affecting subse- 
quent iterative performances in performance of operation "repeat". 

If, in continue test step 701 4, the engine determines that performance of responding executed object 6904 
in step 7008 throws an exception other than internal exception "continue", processing transfers from continue 
w test step 7014 to break test step 7016. In break test step 7016, the exception thrown is compared to internal 
exception "break". If the exception thrown is internal exception "break", processing transfers from break test 
step 7016 to terminal step 7018. In terminal step 7018, operation "repeat" completes successfully. Thus, exe- 
cution of selector "break" terminates an iterative performance of responding executed object 6904 and suc- 
cessfully terminates performance of operation "repeat", aborting any remaining subsequent iterative perfor- 
ms mances in performance of operation "repeat". 

If the exception thrown is not internal exception "break", processing transfers from break test step 7016 
to terminal step 7020. In terminal step 7020, the exception thrown by performance of responding executed ob- 
ject 6904 is thrown by operation "repeat" causing operation "repeat" to fail and to propagate the exception. As 
discussed above, operation "catch" can be used to prevent the propagation of the exception, 
w Once integer 691 0 is decremented in step 7005 to a value less than or equal to zero, processing transfers 

from test step 7004 to terminal step 701 8 in which operation "repeat" completes successfully. Performance of 
operation "repeat" by an executed bject produces no results other than thos resulting from performance of 
the executed object in step 7008 of Figure 70. 

Execution of selector "continue" throws internal exception "continu " which is caught by operations "while", 
s e.g., in continu test step 6522 (Figure 65); "loop", e.g., in continue test step 6806 (Figure 68); and "repeat"! 
e.g„ in continu test step 7014 (Figure 70). Th throwing of internal exception "continu "by xecution of se- 
lector "continue" t rminates an iterative performance of an executed object p rforming operation "while", "loop" 
or "repeat". As described more completely above, detection of internal exception "continue" during perfor- 
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mane of operation "while", "loop 0 , or "r peat" causes a subsequent iterative p rformance of the responding 
procedure, .g. t in continue test steps 6522, 6806, and 7014 of Figures 65, 68, and 70, respectively. 

Execution of selector "break" throws internal exception "br ak" which is caught by operations "while", e.g., 
in break test step 6524 (Figure 65); "loop", e.g., in break test step 6808 (Figure 68); and "repeat", e.g., in break 
5 test step 701 6 (Figure 70). As with the throwing of internal exception "continue" discussed above, the throwing 
of internal exception "break" terminates an iterative performance of an executed object in the course of per- 
forming operation "while", "loop", or "repeat". However, throwing internal exception "break" terminates perfor- 
mance of operation "while", "loop", or "repeat" rather than causing a subsequent iterative performance of the 
responding executed object 

10 Internal exceptions "continue" and "break" are distinguishable from other exceptions only in the context 

of operations "while", "loop", and "repeat". Therefore, in the context the following discussion of internal excep- 
tions "continue" and "break", operations "while", "loop", and "repeat" are collectively referred to herein as "the 
relevant operations". As each of the relevant operations detects and takes action in response to internal ex- 
ceptions "continue" and "break", internal exceptions "continue" and "break" are not thrown by either of the rel- 

15 evant operations as are other exceptions. Figure 71 serves as an illustrative example. 

Stack 7104 is a property of process 7102 and represents the thread of execution of process 7102. User- 
defined frame 71 06 is at the bottom of stack 71 04 and records the dynamic state of a performance of operation 
"live". The remaining contents of stack 71 04 from bottom to top are repeat frame 7108, predefined frame 7110, 
which records the dynamic state of a performance of operation loop", and user-defined frame 7112. Thus, 

20 operation "live" in Figure 71 caused performance of operation "repeat" which caused performance of operation 
"loop" which caused performance of yet another feature. 

Suppose that performance of the feature, whose dynamic state is recorded by user-defined frame 7112, 
executes selector "continue" or selector "break". As discussed above, execution of either selector "continu " 
or "break" throws a corresponding internal exception. Any operation which is not designed to catch these in- 

25 ternal exceptions, i.e., any operation other than either of the relevant operations, behaves as if an ordinary 
exception has been thrown (see discussion above regarding exception test step 5210 and terminal step 5212 
of Figure 52A). In this situation, the internal exception is propagated by performance of the feature represented 
by user-defined frame 7112 and is caught by performance of operation "loop" represented by predefined frame 
7110 in the manner discussed above. The internal exception is not propagated by operation "loop" represented 

30 by loop frame 7110 and therefore has no effect on the performance of operation "repeat" represented by repeat 
frame 7108. 

If no relevant operation is currently being performed, i.e., is not present on stack 7104, execution of either 
selector "continue" or selector "break" produces an exception of class "Loop Missing". An exception of class 
"Loop Missing" is not an internal exception and is therefore propagated like any other exception. 

35 If internal exception "succeed" is thrown, i.e., if selector "succeed" is executed, performance of the current 

method terminates successfully. It should be noted that, since predefined features are implemented directly, 
i.e., in the computer instructions which collectively form an engine, only user-defined features are implemented 
by method objects. Therefore, if operation "loop", the dynamic state of a performance of which is recorded in 
predefined frame 7110 (Figure 71), executes selector "succeed", an internal exception "succeed" is thrown, 

40 terminating performance of operation "loop". Since operation "loop" is predefined, operation "loop" does not 
catch internal exception "succeed" and therefore propagates internal exception "succeed", causing the termin- 
ation of operation "repeat", the dynamic state of a performance of which is recorded in repeat frame 71 08. Sim- 
ilarly, as operation "repeat" is predefined, operation "repeat" does not catch internal exception "succeed", 
causing the termination of operation "live", the dynamic state of a performance of which is recorded in user- 

45 defined frame 7106. However, since operation "live" has no predefined implementation, operation "live" ter- 
minates successfully, i.e., does not fail by throwing an exception. Similarly, if the feature whose method is 
the subject of user-defined frame 7112 throws internal exception "succeed", i.e., executes selector "succeed", 
the feature terminates successfully and internal exception "succeed" is caught In such a case, internal ex- 
ception "succeed" has no effect on predefined frame 7110, repeat frame 7108, and user-defined frame 7106. 

50 The operations discussed above, i.e., operations "do", "if", "either", "while", "select", "catch", "loop", and 

"repeat" are performed in the context of the current method. As discussed above, predefined operations are 
not implemented by method objects. The above-listed operations are all predefined and are therefore not im- 
plemented by method objects. The performance of the above-listed op rations in the context of th current 
method is easily described by way of example. 

55 Suppos , forexampl , that the feature whose method is the subj ct off ram 7112 (Figure 71) requests 

performance of one of the above-listed predefined operations, the performance of which is recorded in a pre- 
defined frame (not shown) immediately above user-defined frame 7112 on stack 7104. During perf rmance 
of the predefined operation, property "stack" of user-defined frame 7112 remains "the current stack." Thus, 
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performance of th predefined operation pops arguments from, and pushes results on to, property "stack" of 
user-defined frame 7112. Therefore, th predefined operations listed above are performed in th cont xt of 
the current method. 

The operations discussed above, i.e., operations "do", "if, "either", "while", "select", "catch", "loop", "re- 
peat", "continue" and "break", provide the object-oriented instruction set of the present invention with a sub- 
stantial degree of generality and versatility. Thus, agents are capable of employing sophisticated logic in trav- 
eling from one place to another, depositing and gathering information by interacting with agents found at va- 
rious places. 

Thus, a novel set of computer processes are provided which can direct their own movement through a com- 
puter network, can send multiple active copies of themselves throughout the network and can interact with 
other computer processes found at remote network nodes to thereby transfer information between processes. 
The disclosed set of computer instructions of which the novel set of computer processes are formed is portable 
and general. The set of computer instructions is implemented uniformly on each node of the computer network. 
Classes are made objects within the disclosed instruction set. The instructions of a process in the present in- 
vention are interpreted rather than compiled. Control constructs are provided for resource management, de- 
cision handling, exception handling, and loop constructs. Thus, a portable and general set of computer instruc- 
tions is provided from which the novel set of computer processes are constructed. 

It should be understood that, while a particular set of computer instructions is described herein and in th 
Appendices, the present invention is not limited to the functionality of the instructions described. Therefore, 
the scope of the present invention shall be limited only by the claims which follow. 
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1 INTRODUCTION 

The three major elements of the Telescript technology 
are introduced in this section of this appendix: the 
10 Telescript Instruction Set, i.e. the subject of this 
appendix; the Telescript Engine, which implements the 
Instruction Set; and the Telescript Network, formed by 
interconnecting Engines. 

1-1 Telescript Inst ruction 
15 The Telescript Instruction Set, which is sometimes 

referred to herein as the "Instruction Set", is a set of 
computer instructions which collectively form a 
programming language whose intended field of application 
is distributed systems and applications. The Instruction 
20 Set is both object-oriented and interpreted. In 

Microfiche Appendices E and F, the Instruction Set is 
sometimes referred to as "the Language". 

The most distinctive classes built into the 
Instruction Set are classes "Agent" and "Place". An 
25 agent, i.e. a computer process that is a member of class 
"Agent", is an active object that can examine and modify 
itself, transport itself from one place in a network to 
another, and interact with the other agents it finds 
there. This power is counterbalanced by permits, which 
3 0 enable either a programmer or an administrator to grant 
only particular capabilities to particular agents on 
particular occasions. A place, i.e. a computer process 
that is a member of class "Place", is an active object 
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that can examine and modify itself and that serves as a 
venue for agents and a context in which they can interact. 

An agent goes to a place and there interacts with the 
place and other occupants of the place. Agents and places 
5 cannot interact at a distance. Thus the Instruction Set 
implements remote programming (RP) , not the more familiar 
remote procedure calling (RPC) paradigm. RP improves upon 
RPC by enabling system elements to interact without 
communicating, improving the performance of the 

10 interactions by reducing their latency. Equivalently, RP 
enables system elements to customize one another by 
stationing their own agents- -and thus themselves --in one 
another's domain. 

The Instruction Set strives to achieve these 

15 characteristics: 
Safety 

• The Instruction Set prevents a process from exceeding 
its permit, interfering with another process without 
the latter' s permission, or directly manipulating the 

20 computer on which the process runs. This helps to 

avoid viruses. 
Portability 

• The Instruction Set makes no concessions to the 
hardware or software constraints or peculiarities of 

25 a particular computer system. This enables a process 

to be executed anywhere within or around a network. 
Extendibility 

• The Instruction Set gives to types of information 
object defined by the programmer the same stature as 

30 those built into the Instruction Set. This enables 

extension of the Instruction Set for particular 
purposes . 
Elevation 

• The Instruction Set draws no distinction between 

35 volatile and non- volatile storage. Every information 

object is inherently persistent. This increases a 
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process level of abstraction and decreases the 
process 1 size . 

1.2 Telescript Engine 

A program written in the Instruction Set is brought 
5 to life by a Telescript Engine, which is sometimes 

referred to herein as an "Engine"/ which interprets the 
instructions the program contains. Such a program is 
called a telescript. One Engine can interpret many 
telescripts concurrently. 
10 An Engine can implement the abstractions of the 

Instruction Set without directly relying upon the hardware 
or operating system of the computer on which the Engine 
runs. The Engine does this using standard interfaces to 
the communication, storage, and other subsystems the 
15 Engine requires of the platform. These form the 

Telescript Communication Application Programming Interface 
(API) which is attached as Appendix C and is a part of 
this disclosure and is incorporated herein in its entirety 
by reference. 

2 0 An Engine can implement privileged escapes from the 

abstractions of the Instruction Set. Such escapes enable 
the construction, external to the Engine, of operational, 
administrative, and managerial (OAMJ tools. Such tools 
are vital to the success of large-scale communication 

25 systems. 

1.3 Telescript Netwnrlc 

Two or more Engines can be interconnected. The 
resulting Telescript Network, which is herein sometimes 
called the "Network" is the universe within which agents 
30 travel. The Network encompasses computer systems that 
would be considered clients of other networks, not parts 
of them. 

A computer system is a part of the Network only if 
the system incorporates an Engine and thus provides places 
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from and to which agents can go. This requirement makes 
the Network homogeneous with respect to the structure, as 
well as the transport, of information. 

Engines are interconnected so that they can move 
5 agents among themselves. Agents are serialized, or 
encoded, for this purpose according to the Telescript 
Encoding Rules described in Appendix B. The resulting 
octet string is transported between Engines as prescribed 
by the Platform Interconnect Protocol which is attached as 
10 Appendix F as a part of this disclosure and is 
incorporated herein in its entirety by reference. 

1 - 4 This Append i y 

This appendix is described as follows. 

1.4.1 Scone 

15 This appendix defines Version 0.8 of the Instruction 

Set. The Telescript Encoding Rules, the Telescript 
Protocol, and the Telescript API are all beyond the scope 
of this appendix and are the subject of respective 
Appendices B, F, and C. 

20 one may view the Instruction Set as an instruction 

set for a virtual machine. From this viewpoint, one can 
readily envision still higher-level languages, compilers 
for which produce telescripts. General Magic Inc. of 
Mountain View, California is developing such a language 

25 which is called High Telescript. In the context of 
Appendices A-F of this disclosure, the Instruction Set 
itself is sometimes called Low Telescript. 

1-4-2 Conformance 

A manufacturer of an Engine has to satisfy certain 
3 0 requirements to properly claim conformance to this 
appendix. 

1 - 4 - 3 Conventions 
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These conventions of prose are followed throughout 
this appendix : 

• "The a attribute" means "the attribute whose 
identifier equals a" . 

5 • "is a key" means "equals a key" , and not "is the same 
as a key" . 

• "An x" generally means "a member of X"* and not "an 
instance of X" . 

• "Throws x" generally means "throws a member of X" . 
10 • "Whether statement " means " statement iff true " . 

• Iff means "if and only if", as it does in 
mathematics. 

• MSB stands for "most significant bit". 

• LSB stands for "least significant bit". 

15 Nc-te: Throughout this appendix, notes (like this) are 

explanatory, not definitive. 

1-4.4 Organization 

This appendix is divided into eight sections. 
Section 1 is this introduction. Section 2 introduces the 
20 Instruction Set's major concepts. Section 3 overviews the 
Instruction Set's predefined classes. Section 4 defines 
them in detail • Section 5 defines the Instruction Set's 
syntax . 

Section 6 defines the conventions followed by the 
25 formal definitions of the interfaces to the predefined 
classes. Section 7 comprises those formal definitions. 
Section 8 shows the part of the class graph that comprises 
the predefined classes and no user-defined classes. 

1.4.5 Road Map 

30 Parts of this appendix are definitive, while others 

are merely informative. The definitive sections are 
Sections 1, 2, 4, and 5. In contrast. Sections 3 r 7 and 
8, reorganize material in Section 4, while Section 6 
duplicates aspects of High Telescript . 
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Different audiences require different parts of this 
appendix. Those interested only in the Instruction Set's 
scope and structure need read only Sections 1, 2, and 3. 
A Telescript programmer requires Section 4 as well . A Low 

5 Telescript programmer must master also the portion of 
Section 5 covering character telescripts, while the High 
Telescript programmer need not do so. A High Telescript 
Compiler or Engine implementor requires the portion of 
Section 5 covering binary telescripts . 

0 For Telescript practitioners, Sections 7 and 8 are 

indispensable references . 



1.4.6 References 

This appendix relies upon these other documents: 

ri06461 

15 Information technolocrv - -Universal Coded Character Set 

iUSSl/ ISO/IEC DIS 10646, International Organization 
for Standardization and International 
Electrotechnical Commission, 1990. 

fUnicode^ 

20 The Unicode Standard: Worldwide Cha r acter Encoding . 

Volume l, Version 1.0, The Unicode Consortium, 
Addison-Wesley, 1991 . 

2 TELESCRIPT CONCEPTS 

The Instruction Set defines a variety of concepts, 

25 the most important of which are introduced in this section 
of this appendix. These concepts are divided into 
"models". A subsection is devoted to each model. Within 
each subsection, a lesser subsection is devoted to each 
concept in the model . 

3 0 Being for remote programming, the Instruction Set 

includes concepts spanning the realms of languages, 
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5 operating systems, and networks. Conventionally separate, 

these areas, in this instruction set are brought together. 

2 . 1 Models 

10 The Instruction Set's concepts are divided into 

5 models. This division serves pedagogic purposes alone and 
is not visible, in any sense, at run time. 
The following models are defined: 



15 



20 



25 



30 



40 



45 



50 



Object 

The "Object" model provides object orientation, e.g., 
10 objects, references, classes, operations, and exceptions. 

Execution 

The "Execution" model provides sequential execution, 
e.g. methods, procedures, and identifiers. 

Process 

15 The "Process" model provides multi- tasking, e.g., 

processes, resources, permits, contacts, and ownership. 



Network 

The "Network" model provides network architecture, 
35 e.g., agents, places, trips, meetings, and telenames . 

20 Timekeeping 

The "Timekeeping" model provides means for keeping 
time r e.g., times and calendar times. 

Pattern Matching 

The "Pattern Matching" model provides means for 
25 pattern matching, e.g., patterns. 

The models are presented below in the order in which 
they are listed above. The concepts within each model are 
presented in a logical order. 
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2.2 Object Modgl 

The Instruction Set realizes the "object model" this 
section defines. 



2.2.1 Objects 

An object is the Instruction Set's unit of both 
information and information processing. An object is an 
instance of a class . 

An object may be anything at all, either simple, 
e.g., a boolean, or complex, e.g., a dictionary, 
either passive, e.g., a string, or active, e.g., 
a process . 



15 

Note : 



10 

20 



Note : In messaging, the application for which the 

Instruction Set was conceived, the objects can 
include the messaging system's component parts, 
e.g., its mailboxes and distribution lists; the 
information objects the system transfers, e.g., 
messages and delivery reports; and the elements 
of those information objects, e.g., the fields 
of envelopes. 



35 20 Persistence 

Every object is "persistent". If the Engine fails 
and subsequently recovers, the only effect upon the object 
is its temporary unavailability. 

Size 

25 Every object has a "size" which is the approximate 

45 amount of persistent storage the object occupies, measured 

in octets. 

Hate: An object's size may vary from place to place. 

50 2.2.2 References 
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A "reference" is the means by which an object is 
denoted and accessed. 



Protected v aUnnrotected 

A reference is either "unprotected" or "protected". 
5 An unprotected reference enables the object to be changed, 
while a protected reference does not. An unprotected 
reference can be made protected, but not conversely. 

Cr^frtjon 

There exists one or more references to every object. 
10 Creating an object creates an initial reference to the 

object as well. The reference is protected iff the object 
is immutable. Additional references can be created as 
desired. Created references are protected iff the source 
reference is protected. 

15 Note : Many predefined operations create new references . 

to existing objects and return the references as 
results . 



Comparison 

All unprotected references to an object are 

2 0 equivalent. Changes made using an unprotected reference 

to an object are made to the object, and thus, in effect, 
to all other references to the object. All protected 
references to an object also are equivalent to one 
another . 

25 An unprotected and a protected reference differ in 

two ways which come to light when a protected reference is 
used to request a feature of the object the reference 
denotes. First, if the feature would change the object, 
the feature fails, throwing "Reference Protected". 

3 0 Second, if the feature returns a reference to- -not a copy 

of --one of the object's properties, that reference is 
protected. 
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One can determine whether two references denote the 
same object . 

Discarding 

A reference should be discarded when no longer 
5 needed. if no references to the same object remain, the 
object itself is destroyed. 

Voiding 

The Engine voids references under circumstances this 
appendix defines. A "voided" reference no longer provides 
10 access to an object. The Engine throws "Reference Void" 
rather than push a voided reference onto the stack. 

2.2.3 Classes 

A "class" defines a set of objects, the class' 
"instances", all having the same interface and the same 
15 implementation. The class itself has both an interface 
and an implementation, which are potentially unique to the 
class . 

Predefined vs User-define^ 

A class is either predefined or user-defined. A 
20 "predefined" class, built into the Instruction Set and 
defined in this appendix, represents a kind of object 
available to every Telescript programmer. A 
"user-defined" class, defined by the programmer, extends 
the Instruction Set for specific purposes. 

25 Concret e vs Abshrart 

A class is either concrete or abstract. A "concrete" 
class can have instances. An "abstract" class cannot, but 
its subclasses can and often do. A concrete class, or one 
of its implementation superclasses, shall implement each 

30 feature either native to or inherited by the class. 
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Sealing 

A class, usually concrete, can be sealed. The Engine 

prevents a sealed class from having user-defined, but not 
predefined, immediate subclasses. 

5 Creation 

A concrete class can create a new instance given 
initialization parameters describing the new instance. 
Not every instance of every class, however, can be created 
in this way. The remaining ones can be created by first 
10 creating one instance in this way and then modifying the 
instance's attributes as necessary. 

Conversion 

A concrete class can convert an instance of one class 
to an instance of itself. Not every instance of every 
15 class, however, can be converted to an instance of every 
other class. The definition of operation "convert", and 
the nature of the object conversion produces, depend upon 
the two classes involved. 

Compatibility 

20 A class is embodied as a cited object. One class is 

backward compatible with another iff the former's 
interface can be created from the latter' s by making only 
changes of the following kinds. First, a feature can be 
added. Second, if in the latter' s interface an attribute 

25 is read-only, that attribute's class can be narrowed to a 
subclass. Third, the class of an argument of an existing 
operation can be widened to a superclass. Fourth, the 
class of the result of an existing operation can be 
narrowed to a subclass. 

30 2.2.4 Inheritance 
Native vs Inherited? 
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All classes, both predefined and user-defined, are 
related to one another by "inheritance". Every class has 
various characteristics. In general, some of a class' 
characteristics are "native" to the class, while others 
5 are "inherited" from other classes. Inheritance is a 
transitive relationship. A class inherits from a class 
the latter' s inherited characteristics, as well as the 
latter' s native characteristics. Extending the above 
terminology only slightly, an object's native 
10 characteristics are those native to the class of which the 
object is an instance. 

The Instruction Set sufficiently constrains the 
inheritance relationships among classes that the classes 
and their relationships can be described by simple graphs. 
15 In such a graph, the nodes represent classes, the arcs 
between nodes the inheritance relationship between the 
classes the nodes represent . 

Subclass vs Superclass 

If one class inherits characteristics from another, 

2 0 either directly or indirectly, the former is a "subclass" 
of the latter, and the latter is a "superclass" of the 
former. If one class inherits characteristics from 
another directly, the former is an "immediate subclass" of 
the latter, and the latter is an "immediate superclass" of 

25 the former. 

An instance of a class is a "member" of that class 
and of its superclasses . 

Flavor 

Some classes are flavors. The "flavors", each of 
30 which is either abstract or concrete, form a tree as 

follows. The tree's root represents class "Object". Each 
destination node reached by an arc emanating from any 
given source node represents an immediate subclass of the 
flavor that the source node represents. Thus the source 
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node represents an immediate superclass of the flavor 
represented by each such destination node. Each 
destination node reached by way of one or more arcs in 
succession represents a subclass of the flavor that the 
source node represents. Thus the source node represents a 
superclass of the flavor represented by each such 
destination node. 

Note : Flavors provide single inheritance. 



Mix-in 

10 All other classes are mix-ins. A "mix-in" and its 

zero or more superclasses- -all mix-ins themselves- -form a 
20 second tree as follows. The tree's root is the mix-in. 

The arcs represent the inverse inheritance relationship 
between the mix-ins that the tree's nodes represent. A 
15 mix-in is abstract. 

Note : Mix-ins provide a limited form of multiple 

inheritance . 

30 Class Graph 

The flavors and mix-ins together form a directed 
20 graph. The graph is constructed in the following two 

steps. First, the arcs in each mix-in tree are reoriented 
to represent the inheritance relationship, rather than its 
inverse. Second, the thusly altered mix-in trees are 
superposed upon the flavors tree. 
25 Note: There is one, global class graph, achieved by 

identifying classes globally. In any particular 
place, knowledge of the graph may be incomplete. 

45 Canonical Order 

A class, either a flavor or a mix-in, and its 
30 superclasses, both flavors and mix-ins, have a "canonical 
order" which is that of a walk of a third tree. 

The tree is formed as follows. Its root is the class 
in question, its other nodes the class' superclasses. As 

55 
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in a mix-in tree, the arcs represent the inverse 
inheritance relationship among the classes that the tree's 
nodes represent . 

The walk is a depth- first one in which a class' 
5 immediate superclasses are visited in their canonical 
order, which the class defines. 

Interface vs Implementation 

All of the above can be said about either of three 
sets of class characteristics: the classes' interfaces, 
10 their implementations, or both. This appendix explains, 
either explicitly or implicitly, which of the two sets of 
characteristics is being discussed at any particular point 
within this appendix. 

NQte: More often than not, the classes' interfaces are 

15 in view. 

2.2.5 Features 

A "feature" is an externally visible characteristic 

of an object. Features enable objects to interact. If 

one object possesses a reference to another, the former 
20 can request a feature of the latter. All instances of a 

class have the same features, defined by the interfaces 

native to or inherited by that class. 

A feature "succeeds", when it is used correctly, and 

"fails", at other times. When the feature fails, an 
25 exception is thrown. 

Attribute v? Operation 

Features are of two kinds, attribute and operation. 
Note: Whether a particular feature is made an 

attribute or an operation is, in part, a matter 
30 of taste. 

Sealing 
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A class can seal a feature, either native or 
5 inherited, thereby preventing the feature's implementation 

by user-def ined, but not predefined, subclasses. 

Implementat ion 

10 

5 A class can implement any native feature or any 

inherited feature not sealed by a superclass. In the 
latter case, the class' implementation supersedes the 
15 superclasses' implementations, if there are any. 

Access 

10 The Engine controls access to a feature. A feature's 

20 "access" defines the objects that can use the feature, and 

is one of the following: 

public 

25 Any object can use the feature. 

15 private 

Only the object that has the feature can use it. 

30 

system 

Only the Engine itself can use the feature, which is 
35 predefined . 

20 2.2.6 Attributes 

An "attribute", an object, is any characteristic that 
40 one object, the "requester", can ask another or the same 

object, the "responder" , to get and perhaps set. An 
attribute that cannot be set is "read-only". 

45 25 "orGet" vs "crSet" 

An attribute is exactly equivalent to either one 

operation, if the attribute is read-only, or two, 
^ otherwise. The first operation, denoted symbolically as 

"OfGet", gets the attribute. It has no arguments, and its 
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result is the attribute. The second operation, denoted as 
"aSet" replaces the attribute with a particular object. 
The one argument of operation "aSet" is that object, and 
the operation has no result. 

5 Manual vs Automatic 

A class can implement an attribute either manually, 
automatically, or, iff the class is abstract, not at all. 
To "manually" implement an attribute is to provide methods 
for "aGet" and, if the attribute can be set, "aSet" . To 
10 "automatically" implement an attribute is to let the 
Engine do so, which it does if the attribute is an 
instance attribute, the class is concrete, and neither the 
class nor its implementation superclasses implement the 
attribute. The Engine implements the attribute with a 
15 property of the same identifier. 

The Instruction Set defines the getting and setting 
of attributes with the aid of "getAttribute" and 
"setAttribute" , respectively, internal operations an 
argument of which is the attribute's identifier ("a"), 
20 These two operations get and set, respectively, the 

property associated with the attribute, if the latter is 
implemented automatically, or perform the user-defined 
methods for operations "aGet" and "aSet", otherwise, i.e., 
if the attribute is implemented manually. An attribute's 
25 manual or automatic implementation alike is located using 
the execution model's algorithm for locating the 
implementation of an operation. 

Storage Location 

An attribute that is not read-only behaves by default 
30 as a "storage location". That is, operation "oGet" 

returns the object most recently supplied successfully as 
an argument of operation "aSet" . Exceptions to this 
default behavior shall be called out in the prose 
descriptions of particular attributes. 
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Note: Thus if an attribute exhibiting the default 

behavior is constrained to be a member of class 
"Dictionary", and an instance of a subclass of 
class "Dictionary" is supplied to operation 
5 "aSet", operation "aGet" returns that instance 

of that class, not an instance of class 
"Dictionary" . 

Note: All predefined attributes which are read-only 

exhibit the default behavior. 

10 2.2.7 Operations 

An operation is any task that one object, i.e. "the 
requester" f may ask another or the same object, i.e. "the 
responder", to perform. 

Arguments 

15 The requester supplies the responder with zero or 

more objects, which are the operation's "arguments". An 
operation defines whether the operation's arguments are 
variable or fixed in number and, if the latter, how each 
is constrained. 
2 0 Note: if the arguments are variable in number, none 

may be a mark. 
Note: Of the predefined operations, operations 

"initialize", "makeClasses" , "select" and "new", 
and no others require a variable number of 
25 arguments. 

Result 

The responder can optionally supply the requester 
with a single object, the operation's "result", if the 
operation succeeds. An operation defines whether there is 
30 a result and, if so, how it is constrained. 

2.2.8 Exceptions 



95 



EP 0 634 719 A2 



An "exception" is an object describing the failure of 
either the performance of a method for a feature or, more 
fundamentally, the execution of one of the executed 
objects that are the items in the method's procedure. 
5 A feature fails when its responder "throws" an 

exception in lieu of any result the responder would have 
returned had the feature succeeded. The feature's 
requester "catches" the exception if the requester wishes 
to react to the exception. Otherwise, the Engine 
10 "propagates" the exception, i.e., causes the requester to 
throw the exception. 

2.2.9 Constraints 

A "constraint" defines restrictions that are placed 
upon other objects, which are the constraint's "subjects". 

15 The possible restrictions include the identifier of the 
class of which the subjects shall be members, that class 
itself, whether the subjects shall be instances of that 
class, whether the subjects are permitted to be nils, the 
class just mentioned notwithstanding, and the subjects' 

2 0 passage. 

Passage 

An object may be passed between a feature's requester 
and responder in any of several different ways, which 
determine how the source reference, which the object's 
25 source conveys to the Engine, determines the destination 
reference, which the Engine conveys to the object's 
destination. 

An object's "passage" is one of these identifiers: 
bvRef 

30 The destination reference is the source reference. 

bvUnprotectedRef 
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The destination reference is the source reference, 
but the Engine throws "Reference Protected" if the source 
reference is protected. 

bvProtectedRef 

5 The destination reference is a protected reference to 

the object to which the source reference provides access. 

bvCopv 

The destination reference is an unprotected reference 
to a copy of the object to which the source reference 
10 provides access. The Engine makes the copy for this 

purpose alone. The copy is owned by either the object's 
destination, if a process, or the object's destination's 
owner, otherwise. 



2-2.10 Properties 

15 An object has zero or more properties. Itself an 

object, a "property" is one element of the object's 
internal state, all of the object's properties, taken 
together, constituting the entire internal state. An 
object's properties are internal to it r and thus can be 

20 directly sensed, examined, and modified by that object 
alone . 

An object's properties are partitioned by class. 
Zero or more are native to the object's class, and zero or 
more to each of the class' implementation superclasses. 
25 A property can be directly sensed, examined, and 

modified by the methods of the class to which the property 
is native, but not by the methods native to other classes, 
not even the class' subclasses or superclasses. 

2.2.11 Copying 
3 0 Objects can be copied. A "copy" of one object is 

another object that is indistinguishable from the former 
object except, in general, by means of operation "isSame" 
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and by the fact that the copy can be changed, even if a 
protected reference was used to create the copy. 

A copy generally equals the original from which it 
was fashioned, at least initially. The meaning of "equal" 
5 depends upon the classes of which the original is a 

member. If the class, and thus the copy, are immutable, 
the copy and original remain equal indefinitely. 
Otherwise, they can diverge, as the copy and the original 
are independent . 

10 A copy is created using operation "copy". The Engine 

creates the copy by requesting operation "copy" of each 
property of the original. However, if the Engine finds a 
property to be a reference to an object the Engine has 
copied for this purpose already, the Engine does not make 

15 a second copy of that object, but rather uses a reference 
to the first . 



2-2.12 Object Initialization 

An object's creation entails the object's 
initialization. A method for operation "initialize" can 
20 be native to any class of which the created object is a 
member. The method shall initialize the object's 
properties native to that class. 

Before the Engine requests a method for operation 
"initialize", it sets to nils the properties that are 
25 native to the class to which that method is itself native. 

Initialization Order 

Each method for operation "initialize" shall escalate 
the operation after initializing the properties for which 
the method is responsible, thereby allowing other methods 
30 to do the same. If a method succeeds without escalating 
the operation, the Engine does so for the method. The 
process of escalation visits the class of the created 
object and that class' implementation superclasses in 
canonical order. 
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Initial izationParameters 

A class' "initialization parameters" are the objects 
that the method for operation "initialize" native to that 
class requires for the operation's performance. If the 
5 class is a mix-in, it speaks, by its choice of parameters, 
for itself alone. If the class is a flavor, it speaks for 
itself and its implementation superclasses alike. At 
escalation, a class' method for operation "initialize" 
shall have ensured that the parameters of the classes yet 
10 to follow in the canonical order are on the stack, above 
the topmost mark. After the methods for all classes have 
been performed, class "Object" throws an exception if any 
parameters remain . 

Initialization Privileges 

15 A method for operation "initialize" can use a feature 

of the created object after escalation but not before. 
Even then, the object responds as if it were an instance 
of the class to which the method is native, not the class 
of which the object is an instance. The method can use 

20 other objects' features at any time. 

2.2.13 Object Final izat ion 

An object's destruction entails the object's 
f inalization. A method for operation "finalize" can be 
native to any class of which the destroyed object is a 

25 member. The method shall finalize the object's properties 
native to that class. 

A method for operation "finalize" can optionally 
discard, and thus perhaps destroy, the properties the 
operation finalizes. If the method does not do so, the 

3 0 Engine does. 

Final izat ion Order 

A method for operation "finalize" does not escalate 
the operation. The Engine performs each method whether or 
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not other methods succeed, visiting the class of the 
destroyed object and its implementation superclasses in 
canonical order . 

2.2.14 Class Construction 
5 The Instruction Set, unlike many computer languages, 

enables classes to be created at run time via operation 
"makeClasses" . A class is created on the basis of a class 
definition which defines both the class' interface and the 
class' implementation. 

L0 Identifier Bindings 

A class' interface or implementation typically 
depends upon other classes which the interface or 
implementation denotes by identifiers. A citation is 
bound to each such identifier with the aid of the 

L5 interface's or implementation's "vocabulary" attribute. 

If the identifier equals that of a predefined class, 
the citation is to that class. Otherwise, if the 
identifier equals a key in the "vocabulary" attribute, the 
citation equals the associated value. Otherwise, the 

10 citation equals that of the constructed class, except that 
the citation's "title" attribute equals the class' 
identifier. 

Note: The Instruction Set does not define the 

predefined classes' assigned citations. 

5 Citation Bindings 

A class is bound to a citation with the aid of the 
"privateClasses" and "publicClasses" attributes of the 
current process and the current place, respectively. 

If a cited class is predefined, the cited class is 
0 found in the Engine itself. If it is user-defined, the 
class is sought, and may or may not be found, in the 
"privateClasses" attribute of the current process, and, 
failing that, in the "publicClasses" attribute of the 
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current place, the class being any that is backward 
compatible with the cited class. 

A class is bound to the citation at one of two times. 
If the class' identifier is an item of a procedure, the 
5 class is sought whenever the identifier is executed . 
Otherwise, the class is sought when the class is 
constructed . 

2 . 3 Execution Model 

The Instruction Set realizes the "execution model" 
10 this section defines. 

2.3.1 Method^ 

A "method" is a procedure which is able to separately 
maintain the dynamic state of each of its performances. 
That dynamic state takes the form of a frame. Methods are 
15 used to implement operations, conversions, and selected 
attributes . 

Frame 

A "frame" comprises" a stack and zero or more 
variables. Itself an object, a "variable" is one element 

20 of the dynamic state of a particular performance of the 
frame's method, all of the frame's properties, taken 
together and with the stack, constituting the entire 
dynamic state. A frame's stack and variables are internal 
to the frame, and thus can be directly sensed, examined, 

25 and modified by the frame's method alone. The frame 
itself cannot be manipulated at all. 

Performance 

To "perform" a method is to create a frame, accept an 
offer of objects as the initial items of the frame's 
30 stack, set the frame's variables to nils, perform the 
method's procedure, discard the frame, and, iff the 
procedure succeeded, offer the final items of the frame's 



101 



EP 0 634 719 A2 



stack, having popped them from that stack before 
discarding the frame. The method's performance succeeds 
or fails if the procedure succeeds or fails , respectively. 
At any point in time, the "current method" is the 
5 method currently being performed, the "current frame 11 is 
the frame created for that performance, and the "current 
stack", i.e. "the stack", is that of the current frame. 
Note: If the method implements an operation, the 

objects offered as the initial items of the 
10 stack are the arguments, the topmost of the 

objects offered as the final items the result, 
if there is one. In between these two events, 
the stack holds first the arguments and then the 
result, if there is one, of any operation the 
15 method requests. Items other than the topmost 

item of the stack at completion of the 
operation, if there are any, are objects used 
during performance of the operation to carry out 
intermediate steps of the operation. 

20 2.3.2 Procedures 

A "procedure" comprises zero or more executed 
objects, its "items", which are not among the procedure's 
properties, but rather are more fundamentally a part of 
the procedure. The items are numbered in the range [1, 

25 n] , "n" being the procedure's "length". The procedure is 
"cleared" if its length is zero. An item's number is its 
"position" in the procedure. A "subprocedure" comprises 
zero or more items in adjacent positions within a 
procedure . 

30 Performance 

To "perform" a procedure is to execute its items 
sequentially, in order of increasing position, in the 
current frame. The procedure's performance either 
"succeeds", if each item is executed successfully, or 
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"fails", otherwise. If the execution of any item fails, 
no remaining item is executed. 

2.3.3 Executed Objects 

An "executed" object is permitted as an item of a 
5 procedure . 

Performance 

To "perform" an executed object other than a 
procedure is to execute it . 

Execution 

10 To "execute" an executed object is to do things that 

depend upon whether the executed object is an identifier, 
a modifier, a selector, or something else. Execution 
either "fails", if the Engine throws an exception, or 
" succeeds " , otherwise . 

15 Any executed object other than an identifier, a 

modifier, or a selector is executed by pushing onto the 
stack a protected reference to the executed object. 
Note: The executed objects in question in the 

preceding paragraph are bits, bit strings, 

20 booleans, characters, integers, marks, octets, 

octet strings, procedures, reals, and strings. 

2.3.4 Identifiers 

A particular class, feature, property, or variable is 
denoted by an identifier, as are other constructs and 
25 objects in the Instruction Set. 

Identifier 

An "identifier" distinguishes one object from others 
within its scope by means of the identifier's "text", a 
string whose length is at least one. 

30 Qualified IdentifiPr 
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A "qualified identifier" distinguishes zero or more 
implementations of a feature from zero or more other 
implementations of the same feature. A qualified 
identifier denotes the feature by means of the text of its 
5 identifier. It denotes the implementations- -those either 
native to or inherited by a class- -by means of the text of 
the class' identifier, which is the qualified identifier's 
"qualif ier" . 

Scope 

10 No two identifiers having the same scope shall be 

equal . 

Class 

A class cited by an interface or an implementation is 
denoted by an identifier whose scope is all classes cited 
15 by that interface or implementation. 

Feature 

A feature of an object is denoted by an identifier 
whose scope is all features whether native to or inherited 
by the class of which the object is an instance. 

35 20 Property 

A property of an object is denoted by an identifier 
whose scope is all properties native to the class to which 
the property in question is itself native. 
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Variable 

25 A variable of a frame is denoted by an identifier 

whose scope is all variables defined by the method to 
whose performance the frame pertains. 
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Syntax 

A text or a qualifier shall exclude the characters in 
Table A.l. 



TABLE A-l 




Characters 


Notes 


Control Characters 








U+0000 -- U+001F 


As in ASCII. 




U+007F U+009F 


As above, but with 
Bit 7 one. 


Spaces 


Various 


See [Unicode] §4.2. 
U+0020, U+O0AO, 
etc . 


Svmbols and 


U+0021 -- U+002F 


As in ASCII. 




U+003A -- U+0040 


As in ASCII. 




U+005B U+005E 


As in ASCII. 




U+0060 


As in ASCII. 




U+007B U+007F 


As in ASCII. 




U+O0A1 U+0 0BF 


In Latinl. 




U+00D7 & U+00F7 


Multiplication 
("X") and division 
(*) signs 




U+2000 U+2FFF 


Assigned symbols. 


Private Use 
Characters 


U+E800 U+FDFF 




SDecial Characters 


U+FFFO -- U+FFFD 
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The first character of a text or a qualifier shall 
exclude the characters in Table A. 2, as well as those i; 
Table A.l. 



5 



20 



TABLE A. 2 




Characters 


Notes 


Decimal Dioits 


Various 


See [Unicode] §4.1. 
U+0030-- U+0039, 
etc. 




Non-soacina Marks 


Various 



See [Unicode] §4.5. 





Not£: when one programs in High Telescript, the 

privilege of assigning identifiers the first 
25 character of whose text is an underscore {" ") 

(U+005F) is reserved for the High Telescript 
Compiler itself. 



10 



30 2.3.5 Static Substitu tion ftnl^g 

A procedure is performed as if the substitutions in 
Table A. 3 below had been made. Wherever a subprocedure in 
15 the first column appears in the procedure, the 
35 subprocedure in the same row of the second column replaces 

it. 

Table A. 3 defines each subprocedure using the 
non- terminals used to define telescripts. In the table's 
40 20 first section, "Identifier" stands for either itself or 

"Qldentif ier« . m the second section, "Identifier" stands 
for itself alone. 
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5 



20 



25 



TABLE A. 3 


Subprocedure 


Substituted Subprocedure 


SetAttribute Identifier 


Mention Identifier Swap 
"set At tribute" 


UseStack Identifier 


UseStack Identifier 1 - 2 






GetClass Identifier 


Mention Identifier Self 
l, getClass B 


GetProperty Identifier 


Mention Identifier Self 
"get Property" 


GetVariable Identifier 


Mention Identifier Self 
"getVariable" 


SetProperty Identifier 


Mention Identifier Self 
n setProperty" 


SetVariable Identifier 


Mention Identifier Self 
" setVariable n 


Mention ExecutedObject 


Mention "ExecutedObject 2 " 



l This substitution applies iff the identifier is neither 
that of operation "protect" nor opeation "ref". 



2 This substitution is an identity. 

40 If asked to create a procedure having modifiers 

15 arranged in subprocedures other than those in Table A. 3 or 
Table A. 4 below, the Engine throws an exception. 

An internal operation, discussed in Section 3.2.12 of 
45 this appendix, succeeds only if requested as the result of 

one of the substitutions in Table A. 3 or Table A. 4. An 
20 internal operation is otherwise inaccessible. 

50 
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2.3.6 Dynamic Substitution RuIpr 



A procedure is performed as if the substitutions in 
Table A. 4 had been made as well. In Table A. 4 , 
"Identifier" stands for either itself or "Qldentif ier" . 



20 



TABLE A. 4 


Subprocedure 


Substituted Subprocedure 


Identifier 


Mention Identifier Swap 
"getAt tribute 1,1 


Demarcate Identifier 


Mention Identifier Swap 
Demarcate "get Attribute n 1 


Demarcate identifier 


Demarcate Identifier 2 







10 'This substitution applies iff the identifier denotes an 
attribute . 

2 This substitution, an identity, applies iff that of Note 1 
does not, i.e., if the identifier does not denote an 
attribute. 



35 



40 



15 2.3.7 Selector Executing 

A "selector- achieves a special execution effect. 
A selector is executed as follows: 

break 

Makes operation "loop", "repeat", or "while" succeed. 
20 "Loop Missing" is thrown if neither operation is being 
performed . 

45 client 

Pushes onto the stack an unprotected reference to the 
current client. The "current client" is either the object 
2 5 requesting the feature the current method implements, 

50 
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unless the requester is the Engine itself, e.g., if the 
feature's access is "system" , or a nil, otherwise. 

continue 

Makes operation "loop", "repeat", or "while" begin 
5 its next performance, if any. "Loop Missing" is thrown if 
neither operation is being performed. 

escalate 

Is the same as executing an identifier for the 
operation that the current method implements, with these 
10 exceptions. Before method selection, the Engine throws 
"Escalation Invalid" if the requester is not the 
responder. During method selection, the Engine bypasses 
the class to which the current method is native. The 
operation has been escalated. 

15 here 

Pushes onto the stack an unprotected reference to the 
current place. The "current place" is either the place 
the current process occupies, unless the process is an 
engine place, or a nil, otherwise. 

20 process 

Pushes onto the stack an unprotected reference to the 
current process. The "current process" is that of which 
the current method's performance is dynamically a part. 

self 

25 Pushes onto the stack a reference to the current 

object. The "current object" is that performing the 
current method. The reference is protected iff a 
protected reference was used to request the current 
method's performance. 

30 succeed 
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Causes the current method to succeed without its 
remaining items having been executed- The attribute or 
the operation's result, if there is one, shall be on the 
stack . 

5 2.3,8 Modifier Execution 

A modifier alters the execution of the item that 
follows it in a procedure. 

The execution of various modifiers is provided for by 
the substitution rules. A modifier that the substitution 
10 rules leave intact is executed as follows: 

demaycfrtg 

Causes the following identifier, or qualified 
identifier, to be executed with these changes. If the 
stack does not include a mark, the Engine throws "Mark 

15 Missing" . if the number of arguments required by the 
operation that the identifier denotes is fixed and less 
than the number of objects above the mark, the Engine 
throws "Argument Invalid". Otherwise, if the number of 
arguments is fixed and greater than the number of objects 

20 above the mark, the Engine inserts in the stack, between 
the mark and the objects supplied, as many nils are there 
are arguments missing. The Engine then excludes the mark 
from the stack and, if the operation succeeds but does not 
produce a result, returns a nil to the requester, in place 

25 of a result. 



mention 

Avoids executing the object following the "mention" 
modifier, pushing a protected reference to that object 
onto the stack instead. 



30 useStack 

Pushes onto the stack a reference to the stack itself 
before executing the following object. 
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2.3.9 Identifier Execution 

The execution of an identifier for a class, an 
attribute, a property, or a variable is provided for by 
the substitution rules described above with respect to 
5 Tables A. 3 and A. 4 . 

Identifier 

An identifier that the substitution rules leave 
intact --one for an operation- -is executed as follows. 

The Engine throws "Responder Missing" if the stack : 
10 cleared, since the responder was to have been on top of 
the stack. The Engine throws "Feature Unavailable" if 
either the responder lacks the operation the identifier 
denotes or the requester lacks access to the operation. 
Otherwise, the Engine selects and performs a method for 
15 the operation as described in the sections below. 

Qualified Identifier 

A qualified identifier for an operation is executed 
in the same way as is an identifier which is not a 
qualified identifier, for that operation, with these 
20 exceptions. 

Before method selection, the Engine throws 
"Escalation Invalid" if the requester is not the 
responder. Otherwise, the Engine requests operation 
"getClass", its argument being an identifier whose text i 
25 the qualifier, and throws "Escalation Invalid" if the 
operation's result is neither the class to which the 
current method is native nor one of its immediate 
implementation superclasses. 

During method selection, the Engine confines itself 
30 to the result of operation "getClass" and its 

implementation superclasses. The operation has been 
escalated. 
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2.3.10 Method Selection 

The Engine selects for an operation the first method 
it finds by searching the following four locations in the 
order in which they are listed here: 
5 • If the responder is a class, its class methods. 

• If the responder is a class, the class methods of its 
implementation superclasses, which are investigated 
in canonical order. 

• The instance methods of the responder 's class. s 
10 • The instance methods of the implementation 

superclasses of the responder' s class, which are 
investigated in canonical order. 

If a method escalates the operation, the Engine 
attempts to select another, resuming its search after the 
15 class to which the method it selected previously is 
native. If it finds no method, the Engine throws 
"Escalation Invalid" . 

2.3,11 Method Performance 

The Engine performs, as follows, the method it 
20 selects for an operation. 

Arguments Fixed in Number 

If the operation requires a fixed number of 
arguments, the Engine throws "Argument Missing" if the 
stack's length is less than one plus that number, and 
25 throws "Argument Invalid" if an argument violates the 
argument ' s constraint . 

Arguments Variable in NtimHe-r- 

If the operation requires a variable number of 
arguments, the Engine throws "Mark Missing" if the stack 
3 0 does not include a mark, and throws "Argument Invalid" if 
an argument violates the argument's constraint. 

Performance 
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The Engine pops the responder from the stack, creates 
a frame for the method's performance, performs the method, 
and discards the frame. 

The following actions surround the method's 
5 performance. The Engine offers the operation's arguments, 
moving them from the requester's stack to the responder' s. 
If the number of arguments is variable, the mark is 
offered in this way as well. The Engine accepts the offer 
of the operation's result, if there is to be one, moving 
10 it from the responder' s stack to the requester's. 

Success 

If the method succeeds and the operation was to 
produce a result, the Engine does the following. If no 
result was produced, the Engine throws "Result Missing". 
15 If the result does not satisfy the result's constraint, 
the Engine throws "Result Invalid". Either exception is 
handled as described below. 

Failure 

If the method fails and the operation was not to 
20 throw the exception it actually threw, the Engine 

substitutes "Unexpected Exception" for that exception. 

2.4 Process Model 

The Instruction Set realizes the "process model" this 
section defines. 



25 2.4.1 Processes 

A "process" is a named, autonomous computation. It 
constitutes the Instruction Set's provision for 
multi- tasking. 

HQts: A process often represents something in the real 

30 world, e.g., a person, whose objectives the 

process seeks to further in the Network. 
Note: There are two kinds of process, agent and place. 
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Interaction 

If one process has a reference to another, the two 
can interact in the same way as can any two objects: by 
means of their respective features. Each argument or 
5 result of such a feature enables one process to convey to 
the other either a reference to, or a copy of, an object. 

2.4.2 Phases 

A process goes through phases. The Engine requests 
and the then potential process successfully performs 
10 operation "initialize". The Engine requests and the 
process successfully performs operation "live", a nil 
being supplied as the operation's argument. The Engine 
requests and the process performs operation "finalize". 

Exceptions 

15 The normal progression of phases described above may 

be interrupted. If operation "initialize" throws an 
exception, the Engine terminates the process. If 
operation "live" throws an exception, the Engine either 
restarts the process by requesting operation "live" again, 

20 the exception being supplied as the operation's argument, 
if the permit the process holds allows this, or requests 
operation "finalize" otherwise. If operation "finalize" 
throws an exception, the Engine terminates the process. 

If the process exhausts its native or local permit in 

25 any phase above, the situation is as if the process had 
thrown "Permit Exhausted". 

2.4.3 Threads 

Every process gives rise to an independent thread of 
execution which comprises, at any moment, the frames of 
30 the methods being performed on the process' initiative. 
The first such method is the one the process itself 
provides for operation "live" the second the one an object 
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provides for a feature that the method for operation 
"live" requests of that object, and so on, recursively. 

Scheduling 

The Engine schedules all execution threads that are 
5 not blocked, e.g., waiting until a certain time, switching 
preemptively between them as necessitated by their 
priorities. All else being equal, the Engine favors 
neither the processes of one authority over those of 
another, the processes of one brand over those of another, 
10 nor one process over another of the same priority. 

Interruption 

When the Engine itself requests a feature of an 
object, i.e., a system feature, the feature's method is 
performed as part of the thread of the object's owner. 
15 The owner, in effect, is interrupted for that purpose. 

2.4.4 Resources 

A "resource" is something about which certain 
guarantees can be made to a process throughout its 
performance of a particular procedure. The Engine may 
20 delay the process until it can make the guarantees. 
Note: Resources enable the definition of critical 

conditional regions. 
Note: a resource is often a proxy for a physical 

resource (as exemplified below) . 
2 5 Note: in an electronic mail system, e.g., an agent 

serving as a mailbox might include among its 
properties a database of delivered messages and 
a resource representing the database. The agent 
would obtain exclusive use of the resource 
30 before beginning the task of adding a newly 

delivered message to the database, thereby 
ensuring the database's integrity in the face of 
concurrent deliveries . 



115 



EP 0 634 719 A2 



Need 

Because one process can convey a reference to an 
object to another process, every object must be prepared 
for the methods native to or inherited by its class to be 
5 performed concurrently by those processes. Resources 
enable objects to make such preparations. 

Resources are used to ensure that sequences of 
operations are carried out atomically. For one operation, 
such precautions generally are not required because the 
10 Engine performs atomically all predefined operations 
except operations "wait", "meet" and any predefined 
operation that performs a procedure supplied as either the 
responder, e.g., operation "do", or an argument, e.g., 
operation "restrict" . 
15 ffote : The Engine performs operations "go" and "send" 

atomically. 

Exclusive vs Shared 

A process can be guaranteed either shared or 
exclusive use of a resource. At any time, either no 
20 processes have use of the resource, one process has 
"exclusive" use of it, or one or more processes have 
"shared" use of it. 

Condition 

A process can be guaranteed that a resource is among 
25 one or more conditions identified when the request is 

made. At any time, a resource has a "condition" which is 
among one or more conditions defined when the resource was 
created. Denoted by an identifier, a resource's condition 
can be examined only by a process with use, shared or 
3 0 exclusive, of the resource, and can be modified only by a 
process with exclusive use of the resource. 

2.4.5 Permit a 
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A "permit" grants capabilities to a process, its 
"subject". The capabilities represented by the bulk of 
the Instruction Set, e.g., the Instruction Set's 
arithmetic operations, are implicitly granted to each 
5 process. Other capabilities are explicitly granted to 
particular processes by means of the permits assigned to 
those processes . 

Note: The principal purpose of permits is, as far as 

possible, to prevent processes from consuming 

10 computer and communication resources in 

unintended amounts. This benefits users, who 
create the processes and may have to pay for 
them, but also providers, who must provide the 
resources that the processes consume. 

15 Note : The resources mentioned above are not to be 

confused with members of class "Resource". 
There is no necessary connection between the 
two. 

Capabilities 

20 A permit grants capabilities in certain defined 

dimensions and amounts . 

A permit can grant a process a certain age, size, 
charges, priority, or authenticity. The charges to which 
a permit entitles its subject is called the subject's 
25 "allowance". An amount in any of these dimensions is an 
integer. Age is measured in seconds, size in octets, and 
charges in "teleclicks » . Priority increases with its 
integer value. Authenticity is region- specif ic. 

A permit can grant a process the right to transport 
30 itself (attribute "canGo" of the permit), create and 

transport clones of itself (attribute "canSend"), create 
other peer processes (attribute "canCreate" ) , set the 
permits of selected processes so as to decrease (attribute 
"canDeny") or increase (attribute "canGrant") their 
3 5 capabilities, increase the actual charges of other 
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processes (attribute "canCharge" ) , or be restarted if 
terminated (attribute "canRestart " ) . An amount in any of 
these dimensions is a boolean, where a boolean whose value 
is "true" grants the right in question. 
5 Each dimension in which a permit can grant 

capabilities is represented by an attribute of the permit. 
If normally an integer, the attribute can be a nil 
instead, in which case the capability is granted in 
unlimited amount. 
10 Note: The charge, in teleclicks, for a service 

rendered to a process, whether by an Engine or 
by another process, can vary from place to 
place, from time to time, or both. The charges 
for some services, e.g., space, can be assessed 
15 per unit time. 

Status 

A process' "status" identifies the process' exercised 
capabilities. The status of a process is the process' 
effective permit", which is described below, except that 
20 the permit's "age", "charges", "extent", and "priority" 
attributes are the process' actual age, charges, size, and 
priority, respectively. 

Effective Permit 

A process' "effective permit" identifies the process' 
25 allowed capabilities. At any time and place, this permit 
is the intersection of the process' native, regional, and 
local permits and any temporary permits in force. For 
this purpose, however, the native permit's "authenticity- 
attribute is considered a nil unless the process is in the 
30 region in which the process was created. 

The -intersection" of two permits is itself a permit, 
each of whose native attributes, Ao, is the intersection of 
the like-named attributes, A, and A,, of the two permits in 
question. More specifically, Ao is either A lt if A, is a 
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a nil; A 2 , if A x is a nil; or the minimum of A x and A 2 , 
otherwise. The Engine notifies a process, e.g., by use of 
operation "restricted" which is described below, if an y of 
the process' permits, once set, is set again. 
5 A process "violates" its permit by attempting to 

exercise a capability in an amount greater than is granted 
the process by the process' effective permit. Violating 
one's permit without also exhausting the permit provokes 
an exception. 

10 A process "exhausts" its permit by allowing the 

process' actual age, charges, or size to reach the age, 
charges, or size, respectively, that the process' 
effective permit would grant the process if none of the 
process' temporary permits were in force. Exhausting 

15 one's permit initiates one's termination. 

Native Permit 

A process' "native permit" identifies the 
capabilities granted to the process by the creator of the 
process. One process, the parent, sets this permit when 
20 the parent creates another process, the child. A peer 
process can decrease but not increase capabilities, if so 
empowered by the peer's own effective permit (attribute 
"canDeny") . 

Capabilities are transferred between processes but 
25 not created. The parent or peer cannot grant the child a 
capability, »x", which the parent or peer does not have 
itself. Let "P« be the amount of "X" granted the parent 
or peer by its effective permit. Let »C« be the amount of 
"X" granted the child by the child's native permit. "c" 
3 0 shall not exceed M P W . 

The charges capability (»x») is conserved. Let "A" 
be the amount of the parent's or peer's actual charges 
beforehand. »c« shall not exceed "P-A" . The amount of 
the parent's or peer's actual charges afterwards is «A+c". 
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Regional Permit 

A process' "regional permit" identifies the 
capabilities granted to the process by the region that 
includes the place the process occupies. A place of the 
5 region's authority can set the permit when the process 
enters the region and at any time thereafter, if so 
empowered by the place's own effective permit (attributes 
"canDeny" and » canGrant ) . if a child enters using 
operation "new", not operation "go- or "send", however, 
10 the child's initial regional permit is made the parent's 
current regional permit. 

Local Pprniif 

A process' "local permit" identifies the capabilities 
granted to the process by the place the process occupies. 
15 The place can set the permit when the process enters and 
at any time thereafter, if so empowered by the place's own 
effective permit (attributes "canDeny" and "canGrant") . 

When entering a place using a ticket, an agent 
requests certain capabilities of the place. The place, 
20 however, decides what capabilities the agent shall have. 
The place can allow the agent to enter with a local permit 
more or less capable than the one the agent requested. in 
the latter case, however, the trip fails, i.e.. operation 
"go" or -send" throws an exception even though the agent 
25 has arrived. 

When entering a place by being created there, a 
process receives as the process' initial local permit one 
created with no initialization parameters. 



30 



Tempor ary Pf-rmits 

A process' zero or more "temporary permits" identify 
the capabilities the process grants itself temporarily. 
Each is put in force using operation "restrict" or 
"sponsor" for a specified procedure's performance. Such 
procedures can be nested. 
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Whenever the Engine requests a system feature, the 
responder's owner implicitly sponsors the operation's 
method using a temporary permit created with no 
initialization parameters. In this way, charges accrue to 
5 the owner. 

Note: Using a temporary permit, a process can hold in 

reserve a portion of the process' allowed age, 
charges, or size. If the process exhausts the 
bulk of this commodity, the process can use the 
10 portion held in reserve to take emergency 

action. 

2.4.6 Ownership 

Every object that is not itself a process is "owned" 
by one. A process and the objects it owns are the 
15 "artifacts" of that process. 

Note: Ownership is not to be confused with authority. 

Object Creation 

Every object, ultimately, is created by passing by 
copy between methods either an argument of a feature or a 
20 feature's result. The new object — the copy that is 

passed- -is owned by either the object to whose method the 
copy is conveyed, if that object is a process, or that 
object's owner, otherwise. 

Object Destruction 
25 When a process is destroyed, all of its artifacts are 

destroyed, and all remaining references to them voided. 

Object Sharing 

A place's artifacts can refer to its immediate 
superplace's artifacts, which constitutes a first realm 
3 0 and its own artifacts and those of its immediate 

subplaces, which collectively constitute a second realm, 
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but the Engine voids a reference passed between the two 
realms . 

Note: Thus fire walls are erected between places. 

2.4.7 Cloning 
5 A process can be given the capability to clone 

itself. A clone is one process that begins as a copy of 
another process, i.e., the "original", with these 
exceptions. 

The clone's identity, but not its authority, differs 
10 from the original's. 

The clone's native permit, which is also its local 
permit, is that given when the clone is created. Any 
temporary permits pending in the original, i.e., as a 
result of operation "restrict are made more restrictive 
15 within the clone to the extent that the clone's native 
permit requires this . 

Wherever the original refers to itself or an object 
the original owns, the clone refers to itself or its own 
copy of that object, respectively. Wherever the original 
20 refers to an artifact of a third process, the clone has a 
voided reference. 

If the original, and thus the clone, are contacted 
objects, the clone's "contacts" attribute is cleared. 

2.4.8 Branding 

2 5 a region brands every process within it. 

A "brand" is a distinguishing mark born by zero or 
more processes in a region. When an agent enters a 
region, the region gives the agent a new brand. When one 
process within the region creates another, the latter 

30 bears the brand of the former. Thus a brand denotes a 
process, e.g., an agent, that entered the region and all 
of the processes created there by the former process. 
Note: Brands enable tracking mechanisms, which are not 

themselves in the Instruction Set. 
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2.4.9 Contacts 

A "contact" represents and documents for one process, 
the "observer", its interaction with a second process, the 
"subject". A "contacted" process receives help from the 
5 Engine in maintaining its set of contacts. 

2.4.10 Isolation 

A process is isolated under various circumstances, 
e.g., upon either parting from all its acquaintances using 
operation "partAll", initiating a trip, or terminating. 

-0 To "isolate" a process is to void each reference to 

an artifact of the process that is held by an artifact of 
any other process, and to void each reference that an 
artifact of the process holds to an artifact of any other 
process. There are two exceptions. First, the place that 

.5 the process occupies retains its references to the 

process, but not to the objects the process owns. Second, 
the process can continue to refer to the place the process 
occupies . 

2.4.11 Termination 

0 A process is terminated in a way that enables the 

methods whose frames are involved in the process' thread 
of execution to conclude gracefully. 

Let (i) A, B, and C be processes, (ii) an artifact of 
A request a feature of an artifact of B, (iii) an artifact 

5 of B in turn request a feature of an artifact of C, and 
(iv) A exhaust its native or local permit. The Engine 
then terminates A as follows. 

Unless A, B, and C are one and the same, the Engine 
throws "Permit Exhausted", returning control to the method 

0 of A, B, or C that most recently prepared, using operation 
"catch" for that exception. The method is resumed, but 
with A holding the local permit of A, B, or C, whichever 
is either the object with which the method is associated 
or that object's owner. When the method finishes, either 
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succeeding or failing, the Engine reinstates the exhausted 
permit of A, re- initiating the above termination 
algorithm. 

After doing the above, the Engine (i) halts A, 
5 (ii) isolates £, (iii) presents A for diagnostic 

examination if the OAM policy in force so requires, and 
(iv) destroys A. 

2.5 Network Model 

The Instruction Set realizes the "network model" this 
10 section defines. 

2.5.1 Agents 

An "agent" is a process that can move from place to 
place . 

An agent can transport itself to a particular 
15 destination via operation "go" or commission one or more 
clones to travel several destinations concurrently via 
operation "send" . 

Note: The "go" and "send" operations of the 

Instruction Set are its most distinctive and 
powerful aspect. In most network architectures, 
all processes are stationary and communicate by 
exchanging messages. In this one, some 
processes are stationary, but others are mobile, 
the former communicating by means of the latter. 
25 This is a paradigm shift. 

2.5.2 Places 

A "place" is a process that is the locale for zero or 
more other processes, each of which can refer to and thus 
interact with the place. 
30 Hote: Places represent the Instruction Set's only 

example of action at a distance. Places 



20 
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inter-act by means of agents which travel between 
them. 

Engine Place vs Virtual Places 

There are two kinds of place. Every Engine sustains 
5 one "engine place", representing the Engine itself, and 
zero or more "virtual" places. 

Subolace vs Superplace 

Any place except an engine place can occupy another 
place. If one place occupies another, either directly or 
0 indirectly, the former is a "subplace" of the latter, and 
the latter is a "superplace" of the former. If one place 
occupies another directly, the former is an "immediate 
subplace" of the latter, and the latter is the "immediate 
superplace" of the former. 

.5 Place Hierarchy 

The places an Engine sustains can be arranged as the 
nodes of a tree, the "place hierarchy", in which the nodes 
represent places, the arcs between nodes the occupation 
relationship between the places the nodes represent . 
0 Note : The tree's root represents the engine place, the 

other nodes virtual places . 

2.5.3 Trips 

A "trip" is an agent's move from one place, the 
trip's "origin", to another or the same place, the trip's 
5 "destination". A trip can fail, leaving the agent either 
at its origin or in a "transit" place, neither its origin 
nor its destination. 

Note: a trip may take a long time because sometimes 

the trip entails transporting the agent by means 
0 of physical, not just logical, communication 

media . 
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Operation "go" vs Operation "s^nri" 

An agent can travel to a single destination itself 
via operation "go" or commission one or more clones to 
travel to several destinations concurrently via operation 
5 "send". 

Note: The "send" operation transports a single 

representation of the agent to any particular 
Engine, even if several clones are being sent to 
places that that Engine sustains. Further 
10 savings, e.g., of space in memory of a computer, 

, can be achieved at that Engine. 

Restrictions 

The operation "go" or "send" shall be requested only 
by either the procedure of a method native to a subclass 
15 of class "Agent » , or a procedure that is an item of such a 
procedure, recursively. The Engine throws "State 
Improper" otherwise . 

2.5.4 Tickets 

A "ticket" describes an intended trip from the 
20 viewpoint of the agent taking the trip. The ticket's main 
purpose is to identify the trip's destination. 

Composition 

A ticket comprises a telename and a teleaddress of 
the destination, a citation to a class of which the 
25 destination is a member, the local permit the agent 
requires at the destination, the time interval within 
which the trip should be accomplished ideally, and the 
time interval within which the trip shall succeed or fail 
under any circumstances. 
3 0 Note: Defining the desired time interval helps the 

Network decide how to distribute its 
communication resources among traveling agents. 
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Note: The effect of defining the maximum time 

interval, which is permitted as a programming 
convenience, also can be achieved by means of 
operation "restrict" . 

5 Satisfaction 

A ticket is satisfied by any place of the identified 
name, address, and class that agrees to the agent's 
arrival within the maximum time interval . 

If no place satisfies the ticket, the Network rejects 
10 the ticket. 

If a set of two or more places satisfy the ticket, 
the Network attempts a trip to successive members of the 
set until one agrees to the agent's arrival or all places 
that the Network approaches reject the agent's arrival. 
15 The order in which the Network approaches the set members, 
to what extent the Network's coverage of the set is 
complete, and whether the Network approaches places that 
join the set after the ticket is presented are undefined. 

2.5.5 Meetings 
20 A "meeting" is an opportunity for two occupants of 

the same place, which are both petitioned objects and thus 
agents, to interact with one another. The requesting 
agent is the "petitioner", the responding agent the 
"petitionee" . 

25 Meeting 

One agent can ask to "meet" another via operation 
"meet". The Engine not the petitioner requests 
operation "meeting" of the petitionee, supplying as an 
argument a contact for the petitioner. Meeting hinges 
30 upon that operation's outcome. 

The Engine gives the two agents references to one 
another iff the meeting is consummated by the success of 
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operation "meeting" . While they are meeting, the two 
agents are said to be "acquaintances 0 of one another. 

The Engine does not serialize meetings with an agent. 
That the agent is performing operation "meeting" already 
5 does not deter the Engine from requesting performance of 
operation "meeting" again. The agent must provide, e.g., 
by means of a resource, any meeting serialization the 
agent requires. 

Parting 

10 Either of the two agents can "part" from one or all 

of its acquaintances, via operation "part" or "partAll", 
respectively. The Engine not the agent requests 
operation "parting" of the agent's acquaintance or 
acquaintances. The Engine supplies as an argument the 

15 contact the Engine before supplied as either an argument 
of operation "meeting" or the result of operation "meet". 
Unlike meeting, a successful parting does not hinge upon 
the outcome of operation "parting"; parting occurs 
immediately and unconditionally. 

20 The Engine voids each agent's references to the 

artifacts of the other. 

The Engine does not serialize partings from an agent. 
That the agent is performing operation "parting" already 
does not deter the Engine from requesting performance of 

25 operation "parting" again. The agent must provide, e.g., 
by means of a resource, any parting serialization the 
agent requires. 

If both agents ask to part from one another, whether 
the Engine requests operation "parting" of either is 

3 0 undefined. 



Restrictions 

The operation "meet", "part", or "partAll" shall be 
requested only by either the procedure of a method native 
to a subclass of class "Agent", or a procedure that is an 
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item of such a procedure, recursively. The Engine throws 
"State Improper" otherwise. 

2.5.6 Petitions 

A "petition" describes an intended meeting from the 
5 viewpoint of the petitioner. Its main purpose is to 
identify the petitionee. 

Composition 

A petition comprises a telename of the petitionee, a 
citation to a class of which the petitionee is a member, 
10 and the time interval within which the meeting attempt 
shall succeed or fail under any circumstances. 
Note: The effect of defining the maximum time 

interval, which is permitted as a programming 
convenience, also can be achieved by means of 
!5 operation "restrict". 

Satisf act-i on 

A petition is satisfied by any petitioned object of 
the identified name and class that agrees to the meeting 
within the maximum time interval. The petitionee must be 

2 0 an occupant of the same place as the petitioner at some 

point within the maximum time interval, but not 
necessarily at its start. 

If no petitioned object satisfies the petition, the 
Engine rejects the petition. 
25 If a set of two or more petitioned objects satisfy 

the petition, the Engine attempts a meeting with 
successive members of the set until one agrees to the 
* meeting or all petitioned objects that the Engine 

approaches reject the meeting. The order in which the 

3 0 Engine approaches the set members, to what extent the 

Engine's coverage of the set is complete, and whether the 
Engine approaches agents that join the set after the 
petition is presented are undefined. 
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2.5.7 Occupation 

The occupants of a place can change over time. 

Entry 

A process can "enter", and thus occupy, a place in 
5 either of two ways. An agent can arrive at the place as a 
consequence of a trip, or one process at the place already 
can create another process of the place. In either case, 
the Engine not the arriving agent or the creating 
process requests operation "entering" of the place. A 
10 contact for the arriving agent or the created process is 
supplied as an argument of operation "entering". 
Successful entry hinges upon the operation's outcome. 

The Engine gives the place and the process entering 
the place references to one another iff the entry is 
15 consummated, i.e., by the success of operation "entering". 
While occupying the place, the process is said to be an 
"occupant" of the place. 

The Engine does not serialize entries to a place. 
That the place is performing operation "entering" already 
20 does not deter the Engine from requesting operation 
"entering" again. The place must provide any entry 
serialization the place requires. 

NQte: Operation "entering" is involved even if a 

trip's origin and destination are the same. 

25 Exit 

A process can "exit", and thus no longer occupy, a 
place in either of two ways. An agent can depart from the 
place as a consequence of a trip, or one process at the 
place can destroy itself or another process at the place. 
30 In either case, the Engine not the departing agent or 
the destroying process requests operation "exiting" of 
the place. The same contact supplied as an argument of 
operation "entering" is supplied as an argument of 
operation "exiting". Unlike entry, a successful exit does 
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not hinge upon the latter operation's outcome; the exit 
already occurred. 

The Engine voids the references of the place and the 
process exiting it to the artifacts of one another. The 
5 Engine, furthermore, isolates the process. 

The Engine does not serialize exits from a place. 
That the place is performing operation "exiting" already 
does not deter the Engine from reque sting operation 
"exiting" again. The place must provide any exit 
10 serialization the place requires. 

Note: Operation "exiting" is involved even if a trip's 

origin and destination are the same. 

2.5.8 Contacts 

The Engine offers places and agents assistance in 
15 maintaining their contacts with their occupants and their 
acquaintances , respectively . 

Occupants 

If a place is also a contacted object, the Engine 
maintains the place's contacts attribute in such a way 
20 that the attribute always includes the place's current 
occupants and none of its previous ones . 

The Engine includes in or excludes from the place's 
attribute a contact for a process at the moment the 
process enters or exits the place, respectively. 

25 Acquaintances 

If a petitioned object is also a contacted object, 
the Engine maintains its contacts attribute in such a way 
that the attribute always includes the object's current 
acquaintances and none of its previous ones. 

30 The Engine includes in the petitioner's or 

petitionee's attribute a contact for the petitionee or the 
petitioner when operation "meet" or "meeting" succeeds, 
respectively. 
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The Engine excludes the contacts from the attributes 
of both the petitioner and the petitionee when either 
process requests operation "part" or "partAll" . 

2.5.9 Citations 
5 Within the Network, objects of certain classes are 

denoted by citations . 

Citations 

A "citation" identifies zero or more cited objects by- 
title and, optionally, author, edition, or both author and 
10 edition. A citation identifies the author by the author's 
authority and, optionally, the author's identity. If a 
citation leaves any of the three characteristics 
undefined, the citation denotes all cited objects with the 
characteristics citation does define . 

15 Author 

An "author" is the process that creates a cited 
object. Thus an author is identified by a telename . The 
authors of all editions of a title are peers. 

Title 

20 A "title" is a series of cited objects, one asserted 

to be backward or forward compatible with another. A 
title is denoted by an identifier, which is interpreted 
relative to the common authority of the title's authors. 

Edition 

25 An "edition" is any of the cited objects in a title. 

An edition is denoted by two integers. One, interpreted 
relative to the title, denotes a major edition. The 
other, interpreted relative to the first, denotes a minor 
edition . 
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Note: A title's first major or minor edition is 

usually assigned the number one or zero, 
respectively. 

Assigned Citations 
5 An "assigned citation" denotes one cited object by 

author, title, and edition, identifying the author by both 
its authority and its identity. The assigned citation 
thereby distinguishes the cited object from all other 
cited objects, and thus from the others in the assigned 
10 citation's own title. See discussion of telenames below. 

Compatibility 

One cited object, 0 2 , is "backward compatible" with 
another, O,, iff Oj can be created by making to O t only 
changes of the kinds prescribed by a class of which both 
15 cited objects are members, the kinds of change chosen to 
ensure that a program written to process O t can process 0 2 
as well. Under the same conditions, O t is "forward 
compatible" with 

2.5.10 Telenames 
20 Within the Network, objects of certain classes are 

denoted by telenames. 

Telenames 

A "telename" identifies zero (if the telename is 
invalid) or more named objects by their authority and, 
25 optionally, their identity. If the telename leaves their 
identity undefined, the telename denotes all named objects 
of the identified authority. 

Authority 

A named object's "authority" is the entity, e.g., the 
30 person or the organization, responsible for the object. 
An authority is identified by an octet string, which 
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distinguishes the authority from all others in the 
Network. 

Two telenames are "peers" iff they identify the same 
authority. 

5 Note : Authorities are created administratively, not 

programmatically * Identities, however, are 
created in both ways. 

Identity 

A named object's "identity" is the named object 
10 itself. An identity, like an authority, is identified by 
an octet string, which, even by itself, distinguishes the 
identity from all others in the Network. 

NQte: The octet string denoting an authority or an 

identity may have no meaning to a human being. 
15 The Instruction Set does not define how the 

octet string is assigned. 

Assigned Te lenames 

An "assigned telename" denotes exactly one named 
object by authority and identity. 

20 2.5.11 Teleaddressefl 

Within the Network, places are located by 
teleaddresses . 

The "Network" comprises all engine places and is 
divided into one or more regions. A "region" is one or 
25 more engine places operated, or provided, by a particular 
authority. 

TeleaddressftR 



134 



EP 0 634 719 A2 



A "teleaddress" identifies zero (if the teleaddress 
is invalid) or more places by their region and, 
optionally, their location. If the teleaddress leaves 
their location undefined, the teleaddress denotes all 
5 places in the identified region. 

Region 

A place's "region" is the region that contains the 
place. A region is identified in the same manner as is an 
authority (see discussion of telenames above) , and thus by 
10 an octet string, which distinguishes the region from all 
others in the Network. 

Location 

A place's "location" is any characteristic of the 
place selected for that purpose by the authority of the 
15 place's region. A location is identified by means of a 
string, which distinguishes the location from all others 
in the region. 

Two places in a region can have the same location. 
Note: The location of a place might be, e.g., the 

20 computer system sustaining it. 

Note: The string denoting a location can, but need 

not, have meaning to a human being. The 
Instruction Set does not define how the string 
is assigned, and the manner of assignment 
25 varies, in general, from one region to another. 

Routing Advice - 

A teleaddress can, but need not, offer advice on the 
routing of agents to the places the teleaddress denotes. 
The teleaddress does this by suggesting one or more 
3 0 regions through which such agents may be routed. In the 
absence of such "routing advice", the Network may be 
unable to transport agents to those places, e.g., if those 
places are far removed from an agent's source. 
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Assigned Teleaddr esses 

An "assigned teleaddress" identifies one or more 
places because several places can have the same 
location --by their region and their location within the 
5 region . 

2.5.12 Interchange 

An "interchanged object" is an immutable object for 
which the Network can, but need not, substitute an 
equivalent object, which is found, e.g., at the 
10 destination, whenever the object's owner takes a trip, on 
which the object must accompany it, provided the 
interchanged object has a digest. Digests are described 
below. 

Note : Interchanged objects improve the performance of 

15 operation "go" and "send" by sometimes allowing 

an Engine to avoid physically transporting the 
interchanged objects by substituting for them 
equivalent objects found, e.g., at the 
destination. 

20 Note: Classes and packages are interchanged objects. 

Digests 

An interchanged object is deemed equivalent to any 
other instance of the object's class whose digest equals 
that of the interchanged object. A "digest" is any 
25 object, other than a nil, that is suited to this purpose. 
For example, a digest can be a mathematical hash of a 
canonical binary representation of the interchanged 
object . 

Note: An interchanged object improves the performance 

30 of operations "go" and "send" only if the object 

is larger than its digest. 

2 • 6 Timekeeping Model 
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The Instruction Set realizes the "timekeeping model" 
5 this section defines. 

One can keep time in two ways. A time or a calendar 
time alike identifies a date and time, but the two differ 
5 in other respects . 
10 Note : Times can be converted to calendar times, and 

conversely. 

Note ; The Engine can internally represent times more 

compactly than it does calendar times. Thus 
10 times are better, in general, for storing and 

transporting dates and times. 



15 



20 



2.6.1 Time 

A "time" identifies a date and time of day to the 
precision of one second using Coordinated Universal Time 
15 (UTC) . A time also identifies the time zone in which the 
25 time was measured and to what extent, if any, Daylight 

Savings Time (DST) was in effect at that time in that 
place . 

Note: UTC is effectively what was formerly known as 

20 Greenwich Mean Time (GMT) . 

2-6.2 Calendar Time 

A "calendar time" has all the characteristics of a 
time, and others. In particular, a calendar time exposes 
to examination and modification the hour of the day, the 
25 minute of that hour, and the second of that minute- It 
exposes the year in the Gregorian calendar, the month of 
that year, and the day of that month. It exposes the days 
of the week and year. It also exposes the time zone's 
permanent offset in minutes from UTC and its seasonal 
30 offset in minutes from its permanent one. The time is DST 
if the latter offset is non-zero. 
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A calendar time makes each facet of the date and time 
of day accessible as an integer that is normally in a 
prescribed range . The hours are numbered in the range of 
[0, 24) , the minutes in the range of [0, 60) , and the 
5 seconds in the range of [0, 6 0] . seconds are numbered in 
the range of [0 , 60], i.e., 61 possible values, to 
accommodate leap seconds. The year 1993, e.g., is denoted 
by the integer 1993, the months are numbered in the range 
[1, 12] , and the days are numbered in the range [1, 31] , 
10 The days of the week are numbered 1, 2, 3, 4, 5, 6 or 7, 
which represent Sunday, Monday, Tuesday, Wednesday, 
Thursday, Friday, and Saturday, respectively. The days of 
the year are numbered in [1, 366] . The permanent and 
seasonal offsets are both numbered in [-720, 720] . 
15 Note: Positive numbers denote years A.D., and negative 

ones denote years B.C. 

Abnormality 

A calendar time may have facets whose integer values 
lie outside their normal ranges. It might identify the 

20 date, e.g., as September 32, by which October 2 is meant. 
Such abnormal values may result from manipulating a 
calendar time in useful ways, e.g., adding two to the day 
of the month, but must be eliminated before the calendar 
time can be considered correct. A calendar time is made 

25 correct in this sense by a process of normalization. 

Normalization 

A calendar time is "normalized" in the following 
steps, the first of which takes into account the fact that 
any facet of a calendar time can be a nil: 

30 Defaults 

• The hour, minute, or second, if nil, is made zero. 
The year, month, or day, if nil, is made one. The 
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permanent or seasonal offset, if nil, is made that of 
a normalized calendar time denoting the current time. 

Offsets 

• The permanent and seasonal offsets are replaced by 
5 the result of transposing into [-720, 720] the 

remainders left by dividing the offsets by 24*60, 
i.e., by the integer value 1440. 

Time 

• The second is placed in normal range by repeatedly 
10 adding or subtracting 60, each time respectively 

subtracting or adding one to the minute. The minute 
is placed in normal range by repeatedly adding or 
subtracting 60, each time respectively subtracting or 
adding one to the hour. The hour is placed in normal 
15 range by repeatedly adding or subtracting 24, each 

time respectively subtracting or adding one to the 
day. 



Date 

20 



, The month is placed in normal range by repeatedly 
adding or subtracting 12, each time respectively 
subtracting or adding one to the year. The day is 
placed in [1, K] by adding or subtracting K, 
respectively subtracting or adding one to the month. 
K is the number of days in the subject month in the 
25 subject year. If one addition or subtraction does 

not place the day in the required interval, this 
entire step is taken again. In other words, the 
month is adjusted as described above before adjusting 
the day again. 



30 Days 



The days of the week and year are set correctly. 
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Localize vs Globalize 

A calendar time can be modified to reflect another 
permanent or seasonal offset without altering the absolute 
point in time it identifies. A calendar time is 
5 "localized" if its offsets are made those of the current 
place. A calendar time is "globalized" if its offsets are 
made those of UTC . 

2 . 7 Pattern Matching Model 

The Instruction Set realizes the "pattern matching 
10 model" this section defines. 

2.7.1 Patterns 

A "pattern" is a means for lexically analyzing a 
string. The pattern's "text", itself a string, prescribes 
the criterion by which a string matches the pattern. 

15 A pattern's text is a series of tokens obeying the 

syntactic, and accompanying semantic, rules below. Given 
in BNF (Backus -Naur or Backus Normal Form) , the rules 
surround optional tokens by brackets ("[" and "]"). They 
surround vertical bar ("|"), left bracket <"["), and right 

20 bracket <"]") by quotation marks ('"') to distinguish 
their use, in accord with BNF, in describing the text of 
any pattern, on the one hand, from their possible use as 
metacharacters in a particular text, on the other. 

Each token in a pattern' s text is zero or more 

25 characters. The text is obtained by concatenating the 
tokens, and thus the characters. 

2.7.2 Structure 
Pattern 

A pattern, i.e., its text, obeys this rule: 
30 Pattern :: = Alternative [" | " Pattern] 
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A string matches a pattern iff it matches any of its 
alternatives . 



Al t e mat ive 

An alternative obeys these rules: 



5 



Al t ernat ive 



Components 



: : = [ A ] Components [$] 

: := Component [Components] 



A string matches an alternative iff successive substrings, 
with no gaps between them, match successive components of 
the alternative. If the alternative begins with a caret 
10 or ends with a dollar sign ("$"), the series of 

substrings must begin or end at the string's beginning or 
end , respectively . 

Component 



A string matches a component iff it either comprises zero 
or more substrings, each matching the item, if an asterisk 
("*") appears; comprises one or more such substrings, if a 
plus sign ( D + ») appears; either matches the item or is 
20 cleared, if a question mark ("?") appears; or matches the 
i t em , otherwi se . 



15 



A component obeys this rule: 
Component ::= Item [* j + | ?] 



Item 



An item obeys this rule : 



Item 



: : - ( Pattern ) | 

" [ n CharacterClass "] " | 

Character 



25 
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A string matches an item iff it matches either the 
pattern, the character class, or the character, whichever 
the item prescribes. 

CharacterClaas 
5 A character class obeys this rule: 

CharacterClass : := [ A ] Characterltems 

A string matches a character class iff it matches the list 
of character items iff the caret D is not present. 

Character! temg 
10 A list of character items obeys these rules: 

Characterltems Characterltem [Characterltems] 

Characterltem CharacterRange | Character 

A string matches a list of character items iff successive 
substrings of the string, with no gaps between them, match 
15 successive character items in the list. The series of 

substrings must begin at the string's beginning and end at 
the string's end. 

CharacterRang p 

A character range obeys this rule: 



20 



CharacterRange : : = Character - Character 

A string matches a character range iff the string 
comprises one character after or equal to the first 
character and before or equal to the second. 
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Character 

A character obeys this rule: 

Character : := . | \ metacharacter j character 

A string matches a character iff the string comprises 
5 either any one character, if a period (".") is present ; 
the metacharacter, if a reverse slash ("\") is present; or 
the character, otherwise. 

Note : Thus the special meaning of a metacharacter is 

avoided if a reverse slash < n \ H ) immediately 
10 precedes the metacharacter. 

2.7.3 Other Non- terminals 
character 

Any instance of class "Character" other than a 
metacharacter. 

15 metacharacter 

A metacharacter. 

2.7.4 Metacharacters 

A pattern's text can include metacharacters. A 
metacharacter has a special meaning which is among the 
20 semantic rules that govern the text. The metacharacters 
are the characters in Table A. 5 and those, e.g., backspace 
tabulated for a character telescript's "String" token. 
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Metacharacter 
Vertical bar ( | ) 
Caret ( A ) 



Dollar sign ($) . . . 

Left parenthesis ( " < " ) 

Right parenthesis < M ) n 
10 Left bracket ( [) 

Right bracket ( ] ) 

Asterisk (*) . . 

Plus sign (+) . . 

Question mark (?) 
15 Minus sign (-) 



Period ( . ) ... 
Reverse slash (\) 
follows . 



TABLE A. 5 
Meaning 

Separates alternatives. 

Either anchors to the string's 

beginning, or inverts the 

matching rules . 

Anchors to the string's end. 

Begins a nested pattern. 

Ends a nested pattern. 

Begins a character class. 

Ends a character class. 

An item zero or more times. 

An item one or more times. 

An item optionally. 

Separates the characters defining 

a range. 

Matches any character. 
Disarms the metacharacter that 



20 3 TELESCRIPT CLASS QVERVTRWfi 

Being object-oriented, the Instruction Set comprises 
certain predefined classes which are overviewed in this 
section of this appendix. These classes are divided into 
groups as discussed below. A subsection is devoted to 

25 each group. Within each subsection, a subsection is 
devoted to each class in the group. 

Being interpreted, the Instruction Set does not 
define statement forms--e.g., for control flow--but rather 
relies upon the operations of its classes. Thus the 

3 0 semantics of the Instruction Set are largely those of the 
predefined classes . 



3 . 1 Groups 

The Instruction Set's predefined classes are divided 
into groups, one of which is called the kernel. This 
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division serves pedagogic purposes alone, and is intended 
to suggest neither that the classes in groups other than 
the kernel can be implemented by means of the kernel, nor 
that an Engine need implement the classes in the kernel 
5 but not necessarily those in other groups . 
The following groups are defined: 

Kernel 

This group provides basic language machinery, e.g., 
classes, objects, references, procedures, execution, and 
10 exceptions. 

Primitives 

This group provides basic forms of indivisible 
information, e.g., boo leans, octets, numbers, characters, 
and times. 

15 Collections 

This group provides basic forms of composite 
information, e.g., sets, lists, stacks, strings, and 
dictionaries. 

Class Definition 
2 0 This group provides the component parts of class 

definitions, e.g., interfaces, attributes, operations, 
implementations, and methods. 

Identification 

This group provides, for naming and addressing, e.g., 
25 telenames and teleaddresses . 

Processes 

This group provides for multi-tasking, e.g., 
processes, permits, resources, and contacts. 

Agents and Places 
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This group provides for process movement within a 
network, e.g., places, agents, and tickets. 



10 



15 



20 



Meetings 

This group provides for process interaction within a 
5 network node, e.g., meeting places and petitions. 

Miscellaneous 

This group provides a variety of things, e.g., a 
random number generator and a pattern matcher. 

The groups are presented below in the order in which 
10 they are listed above. The classes within each group are 
presented in alphabetical order. 



25 



30 



35 



40 



45 



50 



15 



20 



25 



30 



3 . 2 Kernel Group 
Object (Referenced) 

Class (Cited & Interchanged) 
Collection 

• Set (Verified) 

• • Constrained Set (Constrained) 

• 0 • Package (Cited & Interchanged) 
Constraint 

Exception (Unchanged) 

• Programming Exception 

• • Kernel Exception 

• • • Execution Exception 

• • • • Unexpected Exception 
Primitive (Executed & Unchanged) 

• Identifier (Ordered) 

• • Qualifi ed IdentifiPr 

• Mark 

• Modifier 

• Nil 

• Procedure 

• Selector 
Constraint 
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Executed 
5 Referenced 

Unchanged 
Verified 

10 5 3.2.1 Class 

Qperationa 

convert 
is Instance 
isMember 
10 isSubclass 
new 

A "class" is an immutable object that defines a set 
of objects, the class' instances, 

A class' native operations create a new instance via 
15 operation "new% convert an instance of another class to 
an instance of this one via operation "convert", indicate 
whether an object is an instance via operation 
"islnstance" or a member via operation "isMember" of the 
class, and indicate whether another class is a subclass of 
20 the present one via operation "isSubclass". 



15 



20 



25 



30 



3.2.2 Constrained 
35 Attributes 

constraint 

A "constrained object" enforces a constraint upon 
25 those of its properties identified by another class of 
which the object is a member. 

A constrained object's native attribute is the 
constraint (attribute "constraint") . 

Note: Constrained dictionaries, lists, and sets are 

30 constrained objects. 



40 



45 



3.2.3 Constraint 
so Attributes 

classld 
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islnstance 
isOptional 
of Class 
passage 

5 A "constraint" is an object defining restrictions 

placed upon other objects. 

A constraint's native attributes are the identifier 
of the class of which the constraint's subjects shall be 
members (attribute "classld"), the class itself (attribute 
10 "ofClass") , whether the subjects shall be instances of 
that class (attribute "islnstance"), whether the subjects 
may be nils (attribute "isOptional"), and the subjects' 
passage (attribute "passage") . 

3.2.4 Exception 
15 Operations 

throw 

An "exception" is an object describing a performance 
or execution failure. 

An exception's native operation throws the exception 
20 (operation "throw"). 

3-2.5 Executed 
Operations 

catch 
do 

25 either 
if 

loop 

repeat 

while 

An "executed object" is permitted as an item of a 
procedure . 

An executed object's native operations perform the 
executed object (i) once via operation "do", (ii) once 
catching certain exceptions via operation "catch", (iii) 



30 
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10 



15 



once iff a precondition is satisfied via operation "if", 
(iv) a certain number of times via operation "repeat", (v) 
indefinitely many times via operation "loop", or (vi) as 
often as another executed object's performance dictates 
5 via operation "while". An additional operation decides 
which of two executed objects to perform (operation 
"either") . 

Note: Instances of the predefined concrete subclasses 

of class "Primitive", as well as the predefined 
10 subclasses of class "Constrained List", are 

executed objects. 

20 3.2.6 Execution Exception 

An "execution exception" is a kernel exception that 
indicates that the Engine is unable to execute an item of 
15 a procedure. 

Among this class' predefined subclasses is "Internal 
Exception", a member of which indicates that the Engine 
fails to implement an aspect of the Instruction Set. The 
ideal Engine never throws such an exception, but an actual 
20 Engine does. The latter' s documentation says when, e.g., 
when the sum of two integers is too large for the Engine 
to conveniently represent internally. 



25 



30 



35 



40 



3.2.7 Identifier 

An "identifier" is a primitive that distinguishes one 
25 object from others in a particular context. 



3.2.8 Kernel Exception 

A "kernel exception" is a programming exception 
45 thrown by members of the classes in this section. 

3.2.9 Mark 

30 A "mark" is a primitive with one possible value, 

"mark". A mark is used to demarcate a series of objects, 
usually the topmost items of a stack. 

55 
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10 



15 



20 



25 



35 



40 



3.2*10 Modifier 

A "modifier" is a primitive with these possible 
values : "demarcate" , "getClass" , "get Property" , 
"getVariable" , "mention" , "setAttribute" , "set Property" , 
5 "setVariable" , and "useStack". A modifier is used to 
alter the execution of the item that immediately follows 
the modifier in a procedure. 

3 .2.11 Nil 

A "nil" is a primitive with one possible value, 
10 "nil". A nil is used to indicate the absence, e.g,, on 
the stack, of a member of another class. 



3 .2.12 Object 
Attributes 
class 
15 size 
Operations 

copy 

30 finalize 

initialize 
20 isEqual 
select 
Internal Operations 

getAttribute 
getClass 
25 getProperty 
getvariable 
setAttribute 
set Property 
45 setVariable 

30 An "object" is the Instruction Set's unit of both 

information and information processing. An object is an 
instance of a class. 

An object's native attributes are its class ("class") 
and its size ("size") . 

55 
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An object's native operations initialize (operation 
"initialize") and finalize (operation "finalize") the 
object; decide whether the object equals another object 
(operation "isEqual" ) ; decide which, if any, of several 
5 objects the former object equals, and perform the executed 
object paired with that object (operation "select") ; and 
create a separate but equal copy of itself (operation 
"copy" ) . 

An object has a number of internal features. An 

10 "internal" feature is a system feature that is sealed by 
class "Object" and, furthermore, that does not prevent a 
feature native to a user-defined subclass of class 
"Object" from having the same identifier. Thus an 
internal feature is fictitious. Its only purpose is to 

15 simplify the definition of the Instruction Set, especially 
its execution model . 

An object's internal operations bind to objects at 
run time the identifiers used in the interface and 
implementation of the object's class. Thus an object can 

20 (i) get via operation "getAt tribute" , or set, via 

operation "setAt tribute" , the attribute of itself that a 
certain identifier denotes, (ii) get via operation 
"getProperty", or set via operation " set Proper ty " , the 
property of itself that a certain identifier denotes, 

25 (iii) get, via operation "get Variable" , or set, via 
opeation "set Variable" , the variable that a certain 
identifier denotes, and, (iv) identify and locate the 
class that a certain identifier denotes via operation 
"get Class" . 

30 3.2.13 Package 

A "package" is a constrained set of classes. A 
package, furthermore, is a cited object, a peer of each 
class the package comprises. 

One package is backward compatible with another iff 
35 the former can be created from the latter by making only 



151 



EP 0 634 719 A2 



changes of the following kinds. First, a new class may be 
added. Second, an existing class may be replaced with one 
backward compatible with the existing class. 

3.2.14 Procedure 

5 A "procedure" is a primitive comprising an ordered 

set of executed objects. 

3.2.15 Programming Exception 

A "programming exception" is an exception that 
indicates that a programming mistake was made in the 
10 provision or use of a feature. 

3.2.16 Qualified Identifier 

A "qualified identifier" is an identifier that 
denotes a feature and a class to which an implementation 
of the feature is either native or inherited. 

15 3.2.17 Referenced 
Attributes 

isProtected 

Operations 

discard 
20 isSame 
protect 
ref 

A "referenced" object is one to which references can 
be obtained. Its features manipulate the references used 
25 to request them, not the object itself. 

A referenced object's native attribute reveals 
whether a reference is protected (attribute 
"isProtected" ) . 

A referenced object's native operations create new 
30 references to the object (operation "ref"), protected if 
desired (operation "protect"); discard an existing 
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reference (operation "discard"); and say whether two 
references are to the same object (operation "isSame"). 
Note : All objects are referenced objects. The present 

class, then, is defined for purely pedagogic 
5 reasons . 

3.2.18 Selector 

A "selector" is a primitive with these possible 
values: "break", "client", "continue", "escalate", "here", 
"process", "self", and "succeed". A selector is used to 
.0 achieve a special execution effect. 

3.2.19 Unchanged 

An "unchanged" object cannot be changed. The meaning 
of "change" depends upon the other classes of which the 
unchanged object is a member. An unchanged object often 
.5 is described as "immutable" . 

Note : Members of classes "Class", "Exception", 

"Package", "Primitive", and "Time" are 
immutable . 

3.2.20 Unexpected Exception 
0 Attributes 

exception 

An "unexpected exception" is an execution exception 
that indicates that a feature threw an exception whose 
class the feature does not declare. 
5 An unexpected exception's native attribute is the 

undeclared exception (attribute "exception") . 

3.2.21 Verified 
Operations 

verify 

0 a "verified object" can become internally 

inconsistent in one or more ways which depend upon the 
other classes of which the object is a member. 
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A verified object's native operation indicates 
whether the object is internally consistent (operati 
"verify") . 

Note: Sets are verified objects. 

5 3.3 Primitive Group 
Ob j ect (Referenced) 

• Exception (Unchanged) 

• • Programming Exception 

• • • Primiti ve Excep tinn 

10 • Primitive (Executed & Unchanged) 

• • Bit (Ordered) 

• • Boolean (Ordered) 

• • Character (Cased & Ordered) 

• • Number (Ordered) 
15 • • • Integer 

• • • Real 

• • Octet; (Ordered) 

• T^lenumber 

• Time (Ordered & Unchanged) 
20 Cased 

Ordered 

3.3.1 Bit 

A "bit" is a primitive with two possible values, 
"zero " and » one » . 



25 3.3.2 Boolean 
Operations 
and 
not 
or 

30 A "boolean" is a primitive with two possible val 

" false " and " true " . 
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15 



A boolean' s native operations make it capable of 
5 logical conjunction (operation "and"), disjunction 

(operation "or"), and negation (operation "not"). 

3.3.3 Cased 
10 5 Attributes 

is Lower 
isUpper 

Operations 

make Lower 
10 make Upper 

A "cased" object comprises character information. 
Such information, and thus the cased object itself, can be 
upper- case, lower-case , or a mix of the two. 

A cased object's native attributes indicate whether 
15 any character information is lower-case (attribute 
"isLower") or upper -case (attribute "isUpper") . 

A cased object's native operations produce an all 
lower-case (operation "makeLower " ) or an all upper-case 
(operation "makeUpper" ) equivalent of the object. 
20 Note: Two cased objects can be compared without regard 

for their cases by using operation "isEqual" in 
combination with either operation "makeLower" or 
35 operation "makeUpper" . 

Note: Characters and strings are cased objects. 

25 3.3.4 Character 
40 A "character" is a primitive whose possible values 

are the Unicode characters [Unicode] . 
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3.3.5 Integer 
Operations 
30 modulus 
quotient 

An "integer" is a number that is also an integer, 
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15 



25 



30 



35 



40 



An integer's native operations perform integer 
division and produce either the quotient (operation 
"quotient") or the remainder (operation "modulus") that 
results . 

5 Note : Internally the Engine may represent integers 

with only finite precision. Not all integers, 
therefore, are necessarily instances of this 
class in practice. 



3.3.6 Number 
10 Operations 

abs 

20 add 

ceiling 
divide 
15 floor 

multiply 
negate 
round 
subtract 
2 0 truncate 

A "number" is a primitive that is capable of basic 
arithmetic operations . 

A number's native operations perform addition 
(operation "add"), subtraction (operation "subtract" ) , 
25 multiplication (operation "multiply"), and division 

(operation "divide") negation (operation "negate") and 
absolute value (operation "abs" ); rounding (operation 
"round") and truncation (operation "truncate"); and the 
floor (operation "floor") and ceiling (operation 
45 3 0 "ceiling") functions. 

3.3.7 Octet 

An "octet" is a primitive comprising eight bits. For 
50 reference purposes, the bits are designated Bit 7 through 

Bit 0. 
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3.3.8 Ordered 
Operations 

isAf ter 
isBefore 
5 max 
10 min 

An "ordered" object is a member of another class 
whose members can be ordered by placing any one either 
before, after, or coincident with any other. The meanings 
10 of "before" and "after" depend upon that class. 

An ordered object's native operations indicate 
whether one such object is before (operation "isBefore") 
or after another (operation "isAfter"), and which of two 
is the minimum (operation "min") or the maximum (operation 
15 "max") . 

Note: Whether two ordered objects are coincident is 

25 indicated by operation "isEqual". 

Note : Instances of many classes are ordered objects. 
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3.3.9 Primitive 

20 A "primitive" is an object that is an Instruction Set 

primitive . 

Note: Not every Instruction Set primitive is a member 

of this class. 

3.3.10 Pr imi t ive Except ion 

25 A "primitive exception" is a programming exception 

thrown by members of the classes in this section. 

3.3.11 Telenumber 
Attributes 

country 
3 0 extension 
telephone 
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A "telenumber" is an object giving the address of a 
5 telephone instrument in the international, telephone 

network, i.e., a telephone number. 

A telenumber' s native attributes are the code for the 
5 country in which the instrument is located ( "country" ) , 
10 the number the country assigns to the instrument 

("telephone" ) , and its telephone extension, if any 
("extension" ) . 

3 . 3 . 12 Time 
10 Operations 

adjust 

20 interval 

A "time" is an object that identifies a date and time 
of day to the precision of one second using UTC. A time 
15 also records the time zone in which it was measured and to 
25 what extent, if any, DST was in effect then and there. 

A time's native operations adjust the time by any 
number of seconds (operation "adjust") and give the 
interval between the time and another time (operation 

Of) 

20 "interval"). 
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3 . 4 Collection Group 
Object (Referenced) 

Association (Ordered) 
Collection 
• List (Ordered) 

Constra ined List (Constrained) 

• Bit String (Executed) 

• Octet String (Executed) 

• String (Cased & Executed) 
Stack 

Set (Verified) 

Constrained Sgt (Constrained) 
Dictionary 

• Constra ined Dictionary (Constrained) 
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Lexicon 

• Exception (Unchanged) 

• • Programming Exception 

• • • Collection Exception 
5 • Stream 

Hashed 

3.4.1 Association 
Attributes 
key 

10 value 

An "association" is one object that comprises two 
objects, which are the one object's "key" and "value". 

An association's native attributes are its key 
(attribute "key") and its value (attribute "value"). 
15 Note : Associations are used to create dictionaries. 

3-4.2 Bit Strincr 

A "bit string" is a constrained list whose items are 
instances of class "Bit". 



3-4.3 Collection 
20 Attributes 

length 

Operations 

clear 
examine 
25 exclude 
include 
stream 

45 A "collection" is an object that comprises an 

unordered set of zero or more other objects, its "items 0 , 
30 which are among its properties. A collection's "length" 
is the number of the collection's items. The collection 
is "cleared" if its length is zero. A subclass of class 
"Collection" can restrict its members' items. 
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A collection's native attribute is the collection's 
length (attribute "length") . 

A collection's native operations include an object as 
a new item (operation "include") , exclude am existing item 
5 (operation "exclude"), exclude all existing items 
(opeation "clear"), arrange for an item's inspection 
(operation "examine"), and produce a stream whose items 
are those of the collection (operation "stream"). 
Note: A collection's length is unbounded. 

10 3.4,4 Collection Exception 

A "collection exception" is a programming exception 
thrown by members of the classes in this section. 

3.4.5 Constrained Dictinnar-y 

A "constrained dictionary" is a dictionary whose keys 
15 are restricted by means of a constraint, a single 
constraint governing the entire dictionary. 

3.4.6 Constrained List 

A "constrained list" is a list whose items are 
restricted by means of a constraint, a single constraint 
20 governing the entire list. 

3.4.7 Constrained Set: 

A constrained set is a set whose items are restricted 
by means of a constraint, a single constraint governing 
the entire set. 

25 3.4.8 Dictionary 
Operations 

add 

drop 

find 

3 0 get 

reJcey 
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set 

transpose 

A "dictionary" is a set whose items are associations 
A subclass of class "Dictionary" can restrict its members 
5 keys, values, or both. 

A dictionary's native operations include an 
association between a certain key and a certain value as 
new item (operation "add"), exclude the association with 
certain key (operation "drop"), determine a key's 
10 associated value (operation "get"), replace a key's 

associated value (operation "set"), determine a value's 
associated key (operation "find"), replace one key with 
another (operation "rekey"), and transpose two keys 
(operation "transpose") . 

15 3.4.9 Hashed 
Attributes 
hash 

A "hashed" object is a member of another class for 
which a hash function is defined. Each member of that 
20 class computes its own hash, an integer, ensuring that if 
two members are equal, their hashes are equal. 

A hashed object's native attribute is the hash 
function for that object (attribute "hash") . 
EjQ&e: If a dictionary's keys are hashed objects, the 

25 dictionary can, but need not, use attribute 

"hash" in the performance of some of the 
dictionary' s operations . 
Note: No instances of predefined classes are hashed 

obj ects ♦ 

30 3.4.10 Lexicon 

A "lexicon" is a constrained dictionary whose keys 
are identifiers. 

3.4.11 List 
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Operations 

add 
drop 
find 
5 get 

reposition 
set 

transpose 

A "list" is a collection whose items are numbered in 
10 [1, n], »n" being the collection's length. An item's 
number is the item's "position- in the list. 

A list's native operations include an object as a new 
item (operation "add"), exclude an existing item 
(operation "drop") , arrange for an item's inspection 
15 (operation "get"), replace an existing item (operation 
"set"), determine an existing item's position (operation 
"find"), reposition an existing item (operation 
"reposition"), and transpose two existing items (operation 
"transpose") . 

20 3.4.12 Octet Rt-Hng 

An "octet string" is a constrained list whose items 
are instances of class "Octet". 

3.4.13 Set 

Operations 
25 difference 

intersection 
union 

A "set" is a collection no two of whose items are 
equal when included. 
30 a set's native operations compute the union 

(operation "union") or intersection (operation 
"intersection") of two sets and exclude those items in one 
that equal items in the other (operation "difference"). 
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Note: An item's modification in situ, may leave two 

items equal . 

3.4.14 Stack 
Operations 
5 pop 
push 

pushltems 

roll 

swap 

10 A "stack" is a list whose items are usually dropped 

in the order that is the opposite of that in which they 
were added. The stack's "top" is position one, the 
stack's "bottom" the position that is the stack's length. 
A stack's native operations add an object at the top 

15 (operation "push"), add the items of a list at the top 
(operation "pushltems ») , drop the item at the top 
(operation "pop"), transpose the two items at the top 
(operation "swap"), and roll a certain number of the 
topmost items a certain number of positions (operation 
2 0 "roll") . 

3.4.15 Stream 
Attributes 

current 
isDone 
25 next 

A "stream" is an object that provides sequential 
access to the objects in an associated series of objects, 
the stream's "items". A stream never "produces" the same 
item twice, and produces a nil after producing the last 
30 item. 

A stream's native attributes enable it to produce its 
next item upon request (attribute "next"), reproduce the 
item it produced most recently (attribute "current"), and 
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indicate whether or not it has yet produced its last item 
(attribute " isDone") . 

Note: If an item of the stream is itself a nil, this 

fact must be taken into account when 
5 interpreting the "next" or "current" attribute. 



3 .4. 16 String 
Operations 
15 substring 

A "string" is a constrained list whose items are 
10 instances of class "Character" . 

A string's native operation produces a copy of a 
substring (operation "substring") . A substring is a 
series of zero or more characters occupying successive 
positions in a string. A substring is defined by two 
15 positions, P! and P 2 , the substring's items being those at 
positions [Pj, P 2 ) of the string. 



20 



3.5 Class Definition GT-rmp 
30 Object (Referenced) 

Class Definition 
Exception (Unchanged) 

• Programming Exception 

• • Class E xception 
Feature 

• Attribute 

• Operation 
Imnl ementaf inn 
Interface 
Method 

45 

3.5.1 Attribute 
30 Attributing 

constraint 
so isSet 
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An "attribute def inition" , i.e, a member of class 
"Attribute", is a feature definition for an attribute. 

An attribute definition's native attributes define 
how the attribute is constrained (attribute "constraint") 
5 and whether it can be set (attribute "isSet") . The former 
affects both the result of operation n c*Get" and, if the 
attribute can be set, the argument of operation "aSet". 

3.5.2 Class Definition 

Attributes 
10 implementation 

interface 

ma j orEdit ion 

minorEdition 

title 

15 Operations 

makeClasses 

A "class definition" is an object that defines a 
class . 

A class definition's native attributes define the 
20 class' interface (attribute "interface"), implementation 
(attribute "implementation"), title (attribute "title"), 
major edition (attribute "majorEdition" ) , and minor 
edition (attribute "minorEdition") . 

A class definition's native operation creates the set 
25 of one or more classes that a set of as many class 
definitions define (operation "makeClasses"). Any- 
required references among the classes are established as 
the classes are created. The process requesting the 
operation is the classes' author. 

30 3.5.3 Class Exception 

A "class exception" is a programming exception thrown 
by members of the classes in this section. 

3.5.4 Feature 
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Attributes 

exceptions 
isPublic 

A "feature definition" , i. e< a member of class 
5 "Feature", is an object that defines a particular feature 
of every member of the class of whose interface the 
feature definition is a part. 

A feature definition's native attributes define 
whether the feature is public, not private (attribute 
10 "isPublic") , and the classes of which the feature's 

exceptions are members (attribute "exceptions"). A system 
feature is not subject to a feature definition. 

3-5.5 Impleme ntation 
Attribute 

15 classMethods 

f romMethods 

instanceMethods 

properties 

setMethods 
20 superclasses 

toMethods 

vocabulary 

An "implementation" is an object that implements 
selected features and conversions native to or inherited 
25 by the class of which the implementation is a part. 

An implementation's native attributes identify the 
implementation's immediate implementation superclasses 
(attribute "superclasses"); provide methods for selected 
class features (attribute "classMethods"), instance 
30 features (attribute "instanceMethods" and attribute 
"setMethods"), and conversions from (attribute 
"f romMethods") and to (attribute "toMethods") other 
classes; define properties native to the class (attribute 
"properties"); and define the identifiers the 
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implementation uses to denote user-defined classes 
(attribute "vocabulary") . 

3.5.6 Interface 
Attributes 
5 classFeatures 

instanceFeatures 
isAbstract 
sealedClassFeatures 
sealedlnstanceFeatures 
10 superclasses 
vocabulary 

An "interface" is an object that defines the features 
native to the class of which the interface is a part. 

An interface's native attributes define whether the 
15 class is abstract (attribute "isAbstract"), identify the 
class' immediate interface superclasses (attribute 
"superclasses"), define the class' native class features 
(attribute ■ classFeatures ■ ) and instance features 
(attribute "instanceFeatures"), identify the class 
20 features (attribute "sealedClassFeatures") and instance 
features (attribute "sealedlnstanceFeatures") that the 
class seals, and define the identifiers the interface uses 
to denote user-defined classes (attribute "vocabulary") . 

3.5.7 Method 
25 Attributes 

procedure 
variables 

A "method" is an object that is used to implement a 
feature . 

30 A method's native attributes are the method's 

procedure (attribute "procedure") and the identifiers of 
the method's variables (attribute "variables") . 
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3.5.8 Operation 
Attributes 

arguments 
result 

5 An "operation definition", i.e., a member of class 

"Operation", is a feature definition for an operation. 

An operation definition's native attributes define 
whether the operation's arguments are variable or fixed i] 
number and, in the latter case, how each argument is 
10 constrained (attribute "arguments"). The attributes also 
define whether the operation has a result and, if so, how 
the result is constrained (attribute "result") . 

3 . 6 Identification Group 
Ob j ect (Referenced) 
15 • Citation (Ordered) 

• Teleaddrgss 

• Tele name 
Cited 

Named 



20 3.6.1 Citation 
Attributes 

author 

majorEdition 
minorEdi t ion 
25 title 

A "citation" is an object that identifies zero or 
more editions, e.g., classes, in the Telescript Network. 

A citation's native attributes define the title in 
which the editions appear (attribute "title"); optionally, 
30 the title's author (attribute "author"); and, optionally, 
the editions' major edition (attribute "majorEdition"), 
minor edition (attribute "minorEdition" ) , or both. 

3.6.2 Cited 
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Attributes 

citation 

5 

A "cited" object is one having an assigned citation. 
Two cited objects are peers iff the assigned telenames in 
5 their assigned citations are peers . 
10 A cited object's native attribute is the object's 

assigned citation (attribute "citation") . 
Note : Classes and packages are cited objects. 

15 3.6.3 Named 

10 Attributes 

name 

2Q A "named" object is one having an assigned telename. 

Two named objects are peers iff their assigned telenames 
are peers, 

15 A named object's native attribute is the object's 

25 assigned telename (attribute "name") . 

Note: Processes are named objects. 

3.6.4 Teleaddress 
30 Attributes 

20 location 
provider 
^ r ou t ingAdvi c e 

A "teleaddress" is an object that locates zero or 
more places in the Telescript Network. 
25 A teleaddress' native attributes give the places' 

40 region (attribute "provider"); optionally, the places' 

location (attribute "location"); and any routing advice 
(attribute "routingAdvice" ) . 

45 3.6.5 Telename 

30 Attributes 

authority 
50 identity 
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A "telename" is an object that identifies zero or 
more named objects in the Network. 

A telename' s native attributes define the named 
objects' authority (attribute "authority") and, 
S optionally, the single named object's identity (attribute 
"identity") . 



3 . 7 Process Group 
Ob j ec t (Re f erenced ) 
Contact 

Exception (Unchanged) 

• Programming Exception 

• • Process Exception 
Permit (Ordered) 
Process ( Named ) 
Resource 

Contacted 



3.7.1 Contact 
Attributes 

subject 
20 subjectClass 
sub j ectName 
subjectNotes 
A "contact" is an object that represents and 
documents for one process its interaction with another. 
25 A contact's native attributes are the subject 

(attribute "subject") , the subject's assigned telename 
(attribute "subj ectName" ) , the subject's class' assigned 
citation (attribute "subjectClass"), and an object the 
observer maintains (attribute "subjectNotes" ) . Even if 
3 0 the subject attribute is a nil, as it may be, the Engine 
guarantees the authenticity of the other attributes. 
Note: Typically the "subjectNotes" attribute is the 

state of the interaction between the two 
processes from the observer's viewpoint. 
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3.7.2 Contarf^rf 
5 Attribute 

contacts 

A "contacted" object, necessarily a process, receives 
5 help from the Engine in maintaining the object's set of 
10 contacts . 

A contacted object's native attribute is the object's 
contacts (attribute "contacts") . 

Note: instances of no predefined classes are contacted 

10 objects . 

3 * 7 -3 Permit 



15 



20 



40 



45 



so 



A -permit" is an object that grants capabilities to 

process . 



Attribute 
25 15 ag e 

authenticity 

canCharge 

canCreate 

30 

canDeny 
20 canGo 

canGrant 
35 canRestart 

cans end 
charges 
25 extent 

priority 

A permit's native attributes include integers that 
defxne the maximum age (attribute -age-), size (attribute 
extent", , charges (attribute "charges"), priority 
30 (attribute "priority"), and authenticity (attribute 
"authenticity") of the permit's subject. 

A permit's native attributes include booleans that 
can permit the subject to request operation "charge" 
(attribute "canCharge"), operation "go" (attribute 
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"canGo"), operation "send" (attribute "canSend") , or 
^ operation "new" of a subclass of class "Process" 

(attribute "canCreate" ) ; deny {attribute "canDeny") or 
grant (attribute "canGrant") capabilities via certain 
5 permits of certain processes; and be restarted (attribute 
10 "canRestart" ) . 

Operations 

intersection 

A permit's native operation return the intersection 
10 of two permits (operation "intersection") . 

20 3.7.4 Process Excep t- -irm 

A "process exception" is a programming exception 
thrown by members of the classes in this section. 

25 3.7.5 Process 

15 Attributes 

age 
brand 
charges 

localPermit , 
20 permit 

priority 
privateClasses 
regionalPermit 

Qpera^inns 

2 5 charge 
live 

restrict 
45 restricted 

sponsor 
30 wait 
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A "process" is a named object that constitutes an 
autonomous computation. 
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A process' native attributes are the process' age 
(attribute "age"), brand (attribute "brand"), charges 
(attribute "charges"), local permit (attibute 
"localPermit" ) , permit (attribute "permit"), priority 
5 (attribute "priority"), privately held and used classes 
(attribute "privateClasses" ) , and regional permit 
(attribute "regionalPermit 11 ) . 

A process' native operations carry out the process' 
autonomous computation (operation "live"), delay the 
10 computation for a period of time (operation "wait"), 

impose a temporary permit on the process itself (operation 
"restrict"), perform a procedure under a temporary permit 
and the resulting effective permit of the responder's 
owner (operation "sponsor"), and charge another process 
15 for services that the present process provides to the 
other process (operation "charge") . 

3*7.6 Resource 
Attributes 

condition 
20 conditions 
Operations 

use 

A "resource" is an object about which certain 
guarantees can be made to a process throughout the 

25 process' performance of a particular procedure. 

A resource's native attributes are the resource's 
current condition (attribute "condition") and the 
identifiers of the resource's possible conditions 
(attribute "conditions") . 

30 a resource's native operation performs a certain 

procedure once the resource has made the guarantees 
requested of the resource (operation "use") . 

3 - 8 Agent and Place Group 
Ob j ect (Referenced) 
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Authenticate or- 
Excep t ion ( Unchanged ) 

• Trip Exception 
Means 

Process (Named) 

• Agent 

• Place (Unmoved) 
Ticket Stub 

• Ticket 
10 • Wav 

Unchanged 
• Intsycftangecfl 
20 Unmoved 

3.8.1 Acrent 
25 15 Operations 

go 

send 

An "agent" is a process that can move from place to 
30 place . 

20 An agent's native operations transport the agent to 

one destination (operation "go") or one or more clones to 
as many destinations concurrently (operation "send"). 

3-8.2 Authenticator- 

An "authenticator" is an object with which the 
^ 25 Network can authenticate an agent that initiated a trip, 
e.g., as the agent passes between regions. 

Note; Concrete subclasses of class "Authenticator- are 

region-specific and thus user-defined. 



3-8.3 Interchanged 
30 Attribute 

digest 
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An "interchanged" object is an unchanged object for 
which the Network may substitute an equivalent object 
whenever the object's owner takes a trip. 

An interchanged object's native attribute is the 
5 object's digest (attribute "digest"). 

3.8.4 Means 

A "means" is an object that identifies a means, e.g., 
a particular wireless communication medium, by which the 
Network can transport an agent that initiated a trip from 
10 the trip's source, to the trip's destination, or both. 
Note: Concrete subclasses of class "Means" are 

region- specif ic and thus user-defined, 

3.8.5 Place 
Attributes 

15 address 

publicClasses 

Operations 

entering 
exiting 
20 terminate 

A "place" is a process that is the locale for zero or 
more other processes. 

A place's native attributes are the place's address 
(attribute "address") and the place's publicly held and 
25 used classes (attribute publicClasses"). 

A place's native operations pass judgment upon a 
process' proposed entry of the place (operation 
"entering") , take note of the process' exit from the place 
(operation "exiting") , and forcibly terminate an occupant 
3 0 (operation "terminate"), provided the requester is 
sufficiently capable (attribute "canTerminate" of the 
requester's permit) and the occupant's peer. 

3.8.6 Ticket 
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Attributes 

desiredWait 
de s t i na t i onAddr e s s 
destinationClass 
5 destinationNarne 

destinationPermit 
maximumWait 

A "ticket" is a ticket stub that describes an 
intended trip from the viewpoint of the agent taking the 
10 trip. The ticket's main purpose is to identify the trip's 
destination. 

A ticket's native attributes are a telename 
(attribute "destinationNarne") and a teleaddress (attribute 
"destinationAddressa") of the destination, a citation to a 

15 class of which the destination is a member (attribute 
"destinationClass") , the local permit the agent needs at 
the destination (attribute "destinationPermit"), the time 
interval within which, ideally, the trip should be made 
(attribute "desiredWait"), and the time interval within 

20 which, under any circumstances, the trip shall succeed or 
fail (attribute "maximumWait"). 

3.8.7 Ticket St-nh 

AttribuhPfi 

travelNotes 
25 W ay 

A "ticket stub" i s an object that describes the 
results of a trip. 

A ticket stub's native attributes are the way back to 
the trip's origin (attribute "way") and information, 
30 present originally on the ticket, for the exclusive use of 
the agent that initiated the trip (attribute 
"travelNotes") . 

3 - 8 - 8 Trip arropUnn 

Attribute 
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ticketStub 

A "trip exception" is an exception that signifies the 
Network's failure to provide the trip that a ticket 
describes . 

A trip exception's native attribute is the ticket 
stub (attribute "ticketStub") . 



3.8.9 Unmoved 

An "unmoved" object cannot be moved from one place to 
another. An unmoved object often is described as 
10 immovable. 

A reference to an unmoved object is voided if • 
movement of the object is attempted. 
Note; Places are immovable. 



3.8.10 Way 
15 Attributes 

authenticator 

means 

name 

A "way" is an object that identifies a route along 
20 which the Network can transport an agent that initiated a 
trip. 

A way's native attributes are the name of the region 
through which the trip is to proceed (attribute "name") 
and the means (attribute "means") and the authenticator 
25 (attribute "authenticator") to be used to enter that 
region . 
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3 . 9 Meeting Group 
Obj ect (Referenced) 

• Exception (Unchanged) 
30 • m Meeting Exception 

• Petition 

so • Process (Named) 

• • Place (Unmoved) 
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• • • Meeting Place 
Petitioned 

3.9.1 Meeting Excentinn 

A "meeting exception" is an exception that signifies 
5 a meeting place's failure to arrange the meeting that a 
petition describes. 

3.9.2 Meeting Placg 
Operations 

meet 

10 part 

part All 

A "meeting place" is a place that will arrange 
meetings between any two petitioned objects that are among 
its occupants. 

15 A meeting place's native operations begin a meeting 

(operation "meet"), end one (operation "part"), and end 
all meetings involving the requester (operation 
"part All") . 

3-9-3 Petition 
20 Attributes 

agentClass 

agentName 

maximumWait 

A "petition" is an object that describes an intended 
25 meeting from the viewpoint of the petitioner- The 

petition's main purpose is to identify the petitionee. 

A petition's native attributes are a telename of the 
petitionee (attribute "agentName"), a citation to a class 
of which the petitionee is a member (attribute 
30 "agentClass"), and the time interval within which the 
meeting attempt shall succeed or fail under any 
circumstances (attribute "maximumWait"). 
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3.9.4 Petitioned 
Operations 

meeting 
parting 

5 A "petitioned" object, necessarily an agent, can play 

the role of either petitioner or petitionee in the 
establishment of a meeting. 

A petitioned object's native operations pass judgment 
upon a request for a meeting (operation "meeting") and 
10 take note of a parting (operation "parting") . 

Note: Instances of no predefined classes are 

petitioned objects. 

3 . 10 Miscellaneous Group 
Ob j ect (Referenced) 



15 



20 



Calendar Time 
Exception (Unchanged) 

• Programming Exception 

• • Miscel laneous Exception 
Pattern (Ordered) 

Primitive (Executed & Unchanged) 

• Number (Ordered) 

• • Real 
Stream 

• Random Stream 



25 3.10.1 Calendar Time 

Attributes 

day 

dayOfWeek 
dayOfYear 
30 dst 
hour 
minute 
month 
second 
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year 
zone 

Operations 

globalize 
5 localize 
normalize 

A "calendar time" is an object that identifies a 
local date and time of day to the precision of one second 
using UTC. A calendar time also records the local time 
10 zone and to what extent, if any, DST was in effect then 
and there. 

A calendar time's native attributes give the time's 
hour (attribute "hour"), minute (attribute "minute"), and 
second (attribute "second"); the date's year (attribute 

15 "year"), month (attribute "month"), and day (attribute 
"day"); the days of the week (attribute "dayOfWeek") and 
year (attribute "dayOf Year" ) ; and, finally, the time zone 
(attribute "zone") and to what extent DST is in effect 
there (attribute "dst") . 

20 A calendar time's native operations localize 

(operation "localize"), globalize (operation "globalize"), 
or normalize (operation "normalize") the calendar time. 

3-10.2 Miscellaneous Excep tion 

A "miscellaneous exception" is a programming 
25 exception thrown by members of the classes in this 
section. 

3-10.3 Pattern 
Operation^ 

find 

30 substitute 

A "pattern" is an object for lexically analyzing 
strings. The pattern's text, itself a string, dictates 
the exact nature of the analysis. 
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A pattern's native operations search a string for the 
first matching substring (operation "find") or modify all 
matching substrings (operation "substitute") . 

3.10.4 Random Stream 
5 A "random stream" is a stream whose items are 

pseudo- randomly chosen integers in [0, M] . The items are 
determined by an integer- -the seed- -in the same interval. 
A random stream never produces its last item. In one 
embodiment of the present invention, "M" is chosen by the 
10 creator of the random stream and is specified as an 
initialization parameter. 



3.10.5 Real 

A real is a number that constitutes a real number in 
mathematics . 

25 15 No££: Internally the Engine may represent reals- -and 

perform arithmetic operations involving 
them- -with only finite precision. Not all real 
numbers, therefore, are necessarily instances of 
this class in practice, and the results of the 
arithmetic operations, when performed by reals, 
may be only approximate. 
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4 TELESCRIPT CLASS DETAILS 

Telescript's predefined classes are defined, in 
alphabetical order, in this section of this appendix. A 
25 subsection is devoted to each class. 



4 - 1 Conventions 

A class' definition begins with a diagram of the 
^ portion of the class graph that encompasses that class. 

The class itself is underlined. 
3 0 The following sections follow as necessary in the 

discussion of each predefined class. 



so 
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Class 

This section describes the class apart from the 
class' features. The class is formally defined following 
the conventions of Section 6, but an ellipsis (...) 
5 appears in place of the formal definitions of the class' 
features. Described in prose is how, if at all, the 
class' interface's encoding is parameterized (see Section 
6 below) . 

Construction 

10 This section describes operation "initialize" as it 

pertains to members of the class. If this section is 
omitted, a particular description is implied as described 
below in Section 6. 

Subclasses 

15 This section comprises the definitions of the class' 

predefined immediate subclasses. This section is omitted 
iff the class is not a subclass of class "Exception" or is 
a subclass of class "Exception" but has no predefined 
subclasses . 

20 Attributes 

These sections define the attributes native to the 
class. Separate sections are devoted to public, private, 
internal, and other system attributes of the class itself 
and instances of the class. A section is omitted iff it 
25 would be empty. 

An attribute is formally defined following the 
conventions of Section 6. The attribute's semantics and 
exceptions are informally defined in prose. 

Operations 

30 These sections define the operations native to the 

class in the same way that other sections, described, 
define the attributes native to the class. 
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If an operation modifies the stack that holds its 
arguments and result, the operation's effect upon the 
stack is described assuming the arguments have been popped 
from the stack and any result has yet to be pushed onto 
5 the stack. 

Adaptations 

This section describes how the class implements 
features that the class inherits- This section is omitted 
iff the class implements no such features, 

10 Conversions 

This section describes the conversions that produce 
instances of the class. This section is omitted iff there 
are no such conversions. 

The definition of an individual conversion identifies 
15 a source class and states how the source class' members 
are converted to the subject class. If not all members 
can be so converted, which can be converted are indicated. 
If the source class of one conversion is a subclass of the 
source class of another, the former conversion takes 
20 precedence over the latter. Conversions are not chained. 
Note: Conversion is done, i.e., in a single step. 

Thus the conversion of a telenumber to an octet 
string, e.g., is undefined, even though the 
conversion of a telenumber to a string and the 
25 conversion of a string to an octet string are 

defined. 

4.2 Agent 
Ob j ec t ( Re f erenced ) 
• Process (Named) 
30 • • Aaent 

Class 

Agent : 



183 



EP 0 634 719 A2 



abstract interface (Process) = (...); 
Private Instan ce Qper^inno 



TO : 



10 



15 



unprotected op (ticket: copied Ticket) TicketStub 
throws PermitViolated, Statelmproper, TripException; 

Transports the responder to the destination 
identified by the ticket (argument "ticket") subject to 
the ticket's other terms. The operation returns the 
ticket stub. 

An exception is thrown if the responder holds a 
permit that forbids operation "go" ("PermitViolated"), the 
responder' s state precludes operation -go" 
("Statelmproper"), or the trip failed ("TripException"). 

send; 

unprotected op (tickets: copied List [Ticket]) 
TicketStub j Nil 

throws PermitViolated, Statelmproper, 
TripException; 

Transports a clone of the responder to the 
20 destination identified by each and every listed ticket 
(argument -tickets™) subject to the ticket's other terms 
The responder- s allowance is reduced by the amounts the 
ticket, assign to the clones. The operation returns a nil 
for the responder, a ticket stub for each clone. 
25 if a member of either class "Permit Violated" or 

class "State Improper" causes the operation to fail the 
responder experiences the failure, no clones having been 
created. otherwise, the responder experiences the 
operation's success, and each clone, separately and 
30 independently, experiences either the operation's success 
or its failure because of a member of class "Trip 
Exception" . 
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An exception is thrown if the responder holds a 
permit that forbids operation "send" or whose allowance is 
less than the sum of those of the permits on the listed 
tickets ("Permit Violated" ) , the responder' s state 
5 precludes operation "send" ( "State Improper ") , or the trip 
failed ( "TripException" ) . 



4 . 3 Association 

Ob j ect (Referenced) 
• Association (Ordered) 

10 Class 

Association ; 

sealed interface [keyClass, valueClass: Class] 
(Ob j ect , Ordered) = (...); 

25 Parameterized by the classes of which the key 

15 (argument "keyClass") and the value (argument 

"valueClass") of each member of the subject class are 
themselves members . 



20 



Construction 

initialize: 

unprotected op (key: keyClass; value: valueClass) ; 

Makes the responder' s native attributes the 
like -named arguments (argument "key" and argument 
"value" ) . 

Public Instance Attribute 
25 key: 

keyClass; 



The responder' s key. 
so value : 
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valued ass ; 

5 

The responder's value. 

Adaptations 
10 isAfter 

5 One association is after another according to their 
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keys , 



keys 



isBefore 

One association is before another according to their 



10 isEcrual 

Two associations are equal according to their keys, 

4.4 Attribute 
Ob j ect (Referenced) 
• Feature 
!5 • • Attribute 

Class 

Attribute; 

sealed interface (Feature) «(...); 



Construction 
20 initialize ; 

40 unprotected op ( 

constraint : Constraint j Nil ; 
isSet, isPublic: Boolean | Nil; 
exceptions: Set [Identif ier ! ] |Nil) • 



25 Makes the responder's attributes the like-named 

arguments (arguments -constraint", "exceptions" 
'•isPublic", and -ioSet"). If an argument is a nil, 
however, the corresponding attribute is made a constraint 
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with nils as initialization parameters, a cleared set, 
"false" or "false", respectively. 

Public Instance Attributes 
Constraint ■ 
5 Constraint; 

The constraint upon the attribute that the responder 
defines . 



isSet: 
Boolean; 



10 Whether the attribute that the responder defines is 

not read-only. 

25 Adaptat ions 

is Equal 

Two attribute definitions are equal according to 
15 their attributes native to feature definitions and 
attribute definitions. 



4 . 5 Authent icator 
Object (Referenced) 
• Authent icator 

20 Class 

Authenticator : 

abstract interface = <) ; 



4.6 Bit 
45 Object (Referenced) 

25 • Primitive (Executed & Unchanged) 
• • Bit (Ordered) 



Class 
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Bit: 

sealed interface (Primitive, Ordered) = () ; 

Adaptations 
isAf ter 

5 One bit is after another iff the first is one, the 

second zero . 

isBefore 

One bit is before another iff the first is zero, the 
second one. 

10 isEcrual 

Two bits are equal iff both are zero or one. 

Conversions 

BitStrinq 

A bit string having one item produces a bit that 
15 equals that item. 

Boolean 

The booleans false and true produce zero and one, 
respect i vely . 

Character 

20 The numerals zero (0) and one (1) produce zero and 

one , respectively . 

Integer 

The integers zero and one produce zero and one, 
respectively . 

25 Octet 

An octet all of whose bits except Bit 0 are zero 
produces that bit. 
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OctetString 

An octet string that can be converted to an octet 
that can be converted to a bit produces that bit. 

String 

5 A string that can be converted to a character that 

can be converted to a bit produces that bit. 

4.7 Bit Strino 

Ob j ect (Referenced) 

• Collection 

10 • • List (Ordered) 

• • • Constrained List (Constrained) 

• • • • Bit string (Executed) 

Class 

BitStrinq- 

15 sealed interface (ConstrainedList [Bit] , Executed) , 

(..-); 

Construct inn 

initialiser 

unprotected op (segments: Object 

/* Bit (protected BitString! */) ; 



25 



Makes the responder a concatenation of the segments 
(argument "segments") whose positions in the responder 
increase from left to right . 

AdaptafinTifi 

constrainh 

The attribute is sealed. its "ofClass", "classld" 
"xslnstance", » isOptional - , and "passage" attributes are 
class "Bit", the identifier of class "Bit", "true", 
"false", and "byCopy", respectively. 
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isAf ter 

One bit string is after another as if enough "zero" 
bits were first prepended to the shorter bit string to 
make the shorter bit string equal in length to the longer 
5 bit string. 

isBefore 

One bit string is before another as if enough "zero" 
bits were first prepended to the shorter bit string to 
make the shorter bit string equal in length to the longer 
10 bit string. 

Conversions 
Bit 

A bit produces a bit string whose only item equals 
that bit. 

i5 Boolean 

A boolean produces the result of first converting the 
boolean to a bit, and then converting the bit to a bit 
string. 



20 



Character 

A character produces the result of first converting 
the character to an octet string, and then converting the 
octet string to a bit string. 

Integer 

An integer in the range of [-2°, 2°) , for some integer 
25 "n» and none smaller, produces a bit string of length «n" . 
A twos' complement representation is used. The bit at 
position one represents -2». The bit in each position »i» 
in the range of (l, n] represents 2°-*. 

Octet 
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An octet produces the result of first converting the 
octet to an octet string, and then converting the octet 
string to a bit string. 

OctetStrinq 

5 An octet string whose length is "n" produces a bit 

string whose length is »8n". The bit whose position in 
the bit string is (8i+j) is Bit (8-j) of the octet whose 
position in the octet string is "i». in the above, »i» 
and "j" are integers, »i» is in the range [0, n) , and »j» 
10 is in the range [1, 8] . 



String 

A string produces the result of first converting the 
string to an octet string, and then converting the octet 
string to a bit string. 

15 4.8 Boolean 

Object (Referenced) 

• Primitive (Executed & Unchanged) 

• • Boolean (Ordered) 

Class 
20 Boolean = 

sealed interface (Primitive, Ordered) = (...); 

Publi c Instance Operations 
and: 

op (boolean: Boolean) Boolean; 

^ 25 Returns the logical conjunction of the boolean 

(argument "boolean") and the responder. 



50 



not : 

op () Boolean; 
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Returns the logical negation of the responder. 
ox; 

op (boolean: Boolean) Boolean; 

Returns the logical disjunction of the boolean 
5 (argument "boolean") and the responder. 

Adaptations 
isAf ter 

One boolean is after another iff the first is "true", 
and the second is "false". 

10 isBefore 

One boolean is before another iff the first is 
"false", and the second is "true". 

isEoual 

Two booleans are equal iff both are "false" or both 
30 15 are "true" , 

Conversions 
Bit 

A bit produces an indication of whether the bit is 

one . 

20 Character 

A character produces an indication of whether the 
character's Unicode code is non-zero. 

Collection 

A collection produces an indication of whether the 
25 collection's length is non-zero. 

Exception 

An exception produces "true". 
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Nil 

A nil produces " false n . 
Number 

A number produces an indication of whether the number 
5 is non-zero. 

Octet 

An octet produces an indication of whether any of the 
octet's bits is one. 

4 . 9 Calendar Time 
10 Object (Referenced) 
• Calendar Time 

Class 

CalendarTime : 
interface = (...); 

15 Construction 

initialize 

Makes the responder 's native attributes nils. 

Public Instance Attributes 
dav: 

2 0 Integer (Nil; 

Either the day of the month the responder identifies 
or a nil. 

davOf Week : 

readonly Integer | Nil ; 

25 Either the day of the week the responder identifies 

or a nil. 
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davOfYear : 

readonly Integer [Nil; 

Either the day of the year the responder identifies 
or a nil. 

5 dst : 

Integer jNil; 

Either the seasonal offset in minutes, from the 
permanent offset, of the time zone the responder 
identifies or a nil. 

10 hour; 

Integer | Nil ; 

Either the hour of the day the responder identifies 
or a nil. 

minute : 
15 Integer | Nil; 

Either the minute of the hour the responder 
identifies or a nil. 

month : 

Integer | Nil; 

20 Either the month of the year the responder identifies 

or a nil. 



194 



EP 0 634 719 A2 



second : 
Integer | Nil ; 

Either the second of the minute the responder 
identifies or a nil. 

5 year : 

Integer | Nil ; 

Either the year in the Gregorian calendar the 
responder identifies or a nil. 

zone : 

0 Integer) Nil; 

Either the permanent offset in minutes, from DTC, o 
the time zone the responder identifies or a nil. 

Public Instance Operations 
globalize : 
5 unprotected op ( ) ; 

Sets the responder' s permanent and seasonal offsets 
to those of UTC so that the absolute point in time 
identified is unchanged. 

localize : 
0 unprotected op ( ) ; 

Sets the responder' s permanent and seasonal offsets 
to those of the current place so that the absolute point 
in time identified is unchanged. 

normalize : 
5 unprotected op () Boolean; 
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Normalizes the responder and returns an indication of 
whether any of the responder' s attributes were altered in 
the process. 

Adaptations 
5 isEqual 

Two calendar times are equal according to their 
native attributes. 

Conversions 
Time 

10 A time produces a normalized calendar time that 

identifies the same absolute point in time and the same 
permanent and seasonal offsets. 

4.10 Cased 
Cased 

15 Class 

Cased: 

abstract interface () = (...); 

Public Insha nce Att-rjbutes 
isLower ? 

20 abstract readonly Boolean ; 

Whether any item of the responder is lower-case, 
i sUpper; 

abstract readonly Boolean; 

Whether any item of the responder is upper-case. 

25 g-Ublic Instance Q peraM'nnc 
makeLower ? 

abstract op () copied Cased; 
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Returns a copy of the responder in which every 
upper-case item has been replaced with the item's 

5 

lower-case equivalent . 
makeUpper : 

10 5 abstract op () copied Cased; 

Returns a copy of the responder in which every 
lower-case item has been replaced with the item's 
upper- case equivalent . 
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A,,U Character 
20 10 Object (Referenced) 

• Primitive (Executed & Unchanged) 

• • Character (Cased & Ordered) 
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Class 

Character: 

15 sealed interface (Primitive, Cased, Ordered) = () 

Adaptations 
isAf ter 

One character is after another according to their 
Unicode codes. 

20 isBef ore 

One character is before another according to their 
Unicode codes. 

isEqual 

Two characters are equal according to their Unicode 
25 codes. 



50 Conversions 
Bit 
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The bit "zero" produces the numeral zero (0) , and the 
5 bit one produces the numeral one (1) . 

Integer 

An integer in the range of [0, 65535] produces the 
10 5 character with that Unicode code. 

Octet 

An octet produces the result of first converting the 
octet to an integer, and then converting the integer to a 
character. 
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10 OctetStrinq 

An octet string produces the result of first 
converting the octet string to an integer, and then 
converting the integer to a character. 

String 

15 A string having one item produces a character that 

equals that item. 



4 . 12 Citation 
Object (Referenced) 
35 • Citation (Ordered) 



20 Class 

Citation; 

interface (Object, Ordered) = (...); 



Construction 

initialize ; 
25 unprotected op ( 

title: Identifier!; author: Telename | Nil ; 
majorEdition, minorEdition: Integer | Nil) ; 
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Makes the responder 's native attributes the 
like-named arguments (arguments "author", "majorEdition" , 
"minorEdition" , and "title"). 

Public Instance Attributes 
5 author: 

Telename j Nil ; 

Either the telename of the author identified by the 
responder, if the latter is assigned or such a constraint 
is imposed, or a nil, otherwise. 

0 man orEdit ion : 

Integer | Nil ; 

Either the number of the major edition identified by 
the responder, if the latter is assigned or such a 
constraint is imposed, or a nil, otherwise. 

5 minorEdition: 
Integer | Nil; 

Either the number of the minor edition identified by 
the responder, if the latter is assigned or such a 
constraint is imposed, or a nil, otherwise. 

0 title: 

Identifier ! ; 

The identifier of the title the responder identifies . 

Adaptat ions 
isAf ter 

5 One citation is after another iff their "author" 

attributes are peers, their "title" attributes equal, and 
the first citation's "majorEdition" attribute is after 
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the second citation's "majorEdition" attribute or the 
"majorEdition" attributes of both citations are equal and 
the first citation's "minorEdition" attribute is after the 
second citation's. 

5 isBef ore 

One citation is before another iff their "author" 
attributes are peers, their -title" attributes equal, and 
the first citation's "majorEdition" attribute is before 
the second citation's "majorEdition" attribute or the 
10 "majorEdition" attributes of both citations are equal and 
the first citation's "minorEdition" attribute is before 
the second citation's. 

isEqual 

Two citations are equal iff their "author" attributes 
15 are peers and their other native attributes are equal. 

4.13 Cited 
Cited 

Class 

Cited- 

2 0 abstract interface () = (...); 

Construct ion 

initialize : 

unprotected op (title: Identifier!; 

majorEdition, minorEdition: Integer) ; 

25 Makes the responder's native attribute a citation 

whose "author" attribute is the current process' assigned 
telename and whose other attributes are the like-named 
arguments (arguments "majorEdition", "minorEdition" , and 
"title") . 
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Public Instance Attributes 
citation: 

readonly protected Citation; 

The responder's assigned citation. 

5 4.14 Class 

Ob j ect (Referenced) 

• Class (Cited & Interchanged) 



Class 

Class : 

20 10 sealed interface (Object, Cited, Interchanged) 

(.-.); 



Construction 

initialize: 
unprotected op () 
15 throws FeatureUnavailable; 

Throws an exception ("FeatureUnavailable") . 
Note: A class is created using operation 

"makeClasses" , not operation "new". 

Public Ins tance Operations 
20 convert * 

sealed op (source: protected Object) copied Object 
throws ConversionUnavailable; 



Returns either the instance of the responder produced 
45 by converting the object (argument "source") to that 

25 class, if the object is not already an instance of that 
class, or a copy of the object, otherwise. 

The operation looks for a conversion method first in 
the source class and then, failing that, in the 
destination class. An exception is thrown if the object 



55 



201 



BNSDOCID: <EP 063471 9A2 I > 



EP 0 634 719 A2 



10 



15 



cannot be converted as requested 
( "ConversionUnavailable" ) . 

Note: The two steps permit either the source or the 

destination class, whichever was defined later, 
5 to implement the method for a particular 

conversion. 

islnstance : 

sealed op (instance: protected Object) Boolean; 

Returns an indication of whether the object (argument 
10 "instance") is an instance of the responder. 

isMemfrer: 

sealed op (member: protected Object) Boolean; 

Returns an indication of whether the object (argument 
"member") is an interface, but not necessarily an 
15 implementation, member of the responder. 

30 isSubclass : 

sealed op (subclass: Class) Boolean; 
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Returns an indication of whether the class (argument 
"subclass") is a subclass of the responder. 

20 new: 

sealed op (parameters: Object . ..) Object 

throws ClassAbstract, Exception, ObjectUninitialized; 

Returns the new instance of the responder determined 
by the initialization parameters (argument "parameters"). 
2S The signature above notwithstanding, the operation's 

signature is that of operation "initialize" as defined by 
the responder. 
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An exception is thrown if the responder is abstract 
( "ClassAbs tract n ) , a class-specific problem is encountered 
("Exception"), or the potential object uses its own 
features ( "ObjectUninitialized" ) . 

5 4.15 Class D efinition 
Object (Referenced) 
• Class Definition 

Class 

ClassDef inition : 
10 sealed interface = (...}; 

Construction 

initialize : 
unprotected op ( 

title : Identifier ! ; 
15 majorEdition, minorEdition : Integer; 

interface : Interface ; 
implementation : Implementation | Nil ) ; 



Makes the responder' s native attributes the 
like-named arguments (arguments n implementation" , 
35 20 "interface", "majorEdition" , "minorEdition" , and "title") 

Public Instance Attributes 
implementation- 
Implement at ion | Ni 1 ; 

Either the implementation of the class the responder 
25 defines, if there is an implementation, or a nil, 
otherwise . 



interface : 
so Interface ; 
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The interface of the class the responder defines. 

maiorEdition : 
Integer; 

The "majorEdition" attribute of the assigned citation 
5 of the class the responder defines. 

minorEdition : 
Integer; 

The "minorEdition" attribute of the assigned citation 
of the class the responder defines. 

0 title: 

Identifier! ; 

The "title" attribute of the assigned citation of the 
class the responder defines. 

Public Instance Operations 
5 make Classes: 

op (definitions: protected ClassDef inition ...) 

Lexicon [Class] 
throws ClassException; 

Returns a lexicon of the classes the responder and 
0 the other class definitions (argument "definitions") 

define collectively. Each value is the class whose title 
equals the associated key. 

A citation is assigned to each class as follows. The 
assigned citation's "author" attribute is the current 
5 process' assigned telename . The assigned citation's other 
attributes are as defined by the class' class definition. 

An exception is thrown if the- classes cannot be 
created ("ClassException") . 
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Adaptations 
is Equal 

Two class definitions are equal according to their 
native attributes . 

5 4.16 Class Exception 
Ob j ect (Referenced) 

• Exception (Unchanged) 

• • Programming Exception 

• • • Class Exception 



10 Class 
20 ClassExcept ion : 

abstract interface (ProgrammingException) = {) • 



Subclasses 

ClassSealed: 
15 interface (ClassExcept ion) = () ; 

A proposed new class has an immediate superclass that 
is sealed. 

ClaasUndefined : 

interface (ClassException) = (); 

20 A proposed new class uses an undefined class 

identifier. 

FeatureRedef ined : 

interface (ClassException) = () • 

A proposed new class and one of its interface 
25 superclasses have native features denoted by the same 
identifier. 

FeatureSealed ; 
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interface (ClassException) = () ; 

A proposed new class implements a feature sealed by 
one of the class' interface superclasses. 

FeatureUnde fined : 
5 interface (ClassException) - (); 

15 A proposed new class uses an undefined feature 

identifier. 
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MixinDisal lowed : 

interface (ClassException) = (); 

10 A proposed new class uses a mix-in where a flavor is 

required. 

SuperclasseRlnvalid : 

interface (ClassException) = (); 

A proposed new class has immediate superclasses that 
15 are inconsistent. 

4.17 Collection 
Object (Referenced) 
• Collection 

Class 
20 Collection? 

interface [itemClass : Class] » (...); 

Parameterized by the class (argument "itemClass") of 
which each item of each member of the subject class is 
itself a member. 

25 Construction 
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initialize : 

unprotected op (items: itemClass ...) throws 
Itemlnvalid; 

Makes the responder's items the objects (argument 
5 "items") . 

An exception is thrown if a proposed item is invalid 
("Itemlnvalid") . 

Public Instance Attributes 
length: 
.0 readonly Integer; 

The responder's length. 

Public Instance Operations 
clear: 

unprotected op () ; 

5 Removes from the responder and discards all of its 

items . 

Note: The operation reduces the responder's length to 

zero. 

examine : 

0 op (item: protected itemClass) itemClass | Nil ; 

Either leaves in the responder and returns an item 
that equals the object (argument "item"), if there is at 
least one such item, or returns a nil, otherwise. If 
there are several such items, the one selected is 
5 undefined. 

exclude : 

unprotected op (item: protected itemClass) 
itemClass |Nil; 
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Either excludes from the responder and returns an 
item that equals the object (argument "item" ), if there is 
at least one such item, or returns a nil, otherwise. If 
there are several such items, the one selected is 
5 undefined. 

include : 

unprotected op (item: itemClass) throws Itemlnvalid; 

Includes the object (argument "item") in the 
responder as a new item. 
10 An exception is thrown if the proposed item is 

invalid as such ( " Itemlnvalid" ) . 

stream: 

op {) copied Stream [itemClass] ; 

Returns a stream whose items are those of the 
15 responder. A subclass of class "Collection" can define 
the order in which the stream produces the responder' s 
items, but class "Collection" leaves the order undefined. 

If the responder is changed after the stream is 
created, the stream produces newly included items iff the 
20 stream would not have produced them earlier and does not 
produce newly excluded items unless the stream did so 
earlier . 

Note: The subclass of class "Stream" of which the 

stream is an instance is undefined. 

25 Adaptations 
isEoual 

Two collections are equal iff their lengths are equal 
and their items can be paired so as to make the items in 
each pair equal. A subclass of Collection can narrow, but 
30 not broaden, this definition of equality. 
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4 . 18 Collection Exception 
Object (Referenced) 

• Exception (Unchanged) 

• • Programming Exception 

5 • • • Collection Exception 



Class 

Collect ionExcept ion : 

abstract interface (ProgrammingException) - (); 

Subclasses 
0 ItemDuplicated : 

interface (CollectionException) = () ; 



One proposed item of a set equals another. 
Itemlnvalid: 

interface (CollectionException) = (); 

5 A collection's proposed item does not satisfy the 

collection's constraint. 



KevDuplicated : 

interface (CollectionException) = (); 

One proposed key of a dictionary equals another. 

0 K$y Invalid: 

interface (CollectionException) = (),- 

A dictionary's proposed key does not meet the 
dictionary's constraint, or an object purporting to equal 
a key in a dictionary does not. 

5 Obi ectsUnpaired : 

interface (CollectionException) = () ; 
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Supposedly paired keys and values of a dictionary are 
odd in number. 

Po s i t i o n I n va lid: 

interface ( Collect ionExcept ion) = () ; 

5 An integer purporting to equal a position in a list 

or a procedure does not. 

StackDeoleted : 

interface (Collect ionExcept ion) = () ; 

The length of a stack prevents the stack's 
10 manipulation as requested. 



4.19 Const rained 
25 Constrained 



Class 

Constrained : 
15 abstract interface () = (...); 



Cons t rue t ion 

initialize: 

unprotected op (constraint: copied Constraint | Nil) ; 

Makes the responder's native attribute either the 
20 constraint (argument "constraint") , if not a nil, or one 
with nil initialization parameters, otherwise. 



Public Instance Attributes 
« constraint : 

readonly protected Constraint; 



so 



25 The constraint upon nominated properties of the 

responder . 
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4-20 Constrained Dictionary 
Ob j ect (Referenced) 

• Collection 

• • Set 

5 • • • Dictionary 

• • • • Constra ined Dictionary (Constrained) 

ClflSS 

Cons t r ainedDi c t ionary : 

interface [keyClass, valueClass: Class] 
10 (Dictionary [keyClass, valueClass], Constrained) 

= (...); 



Parameterized by the classes of which the key 
(argument "keyClass") and the value (argument 
25 "valueClass") of each item of each member of the subject 

15 class are themselves members. 



Construction 

initialize : 

unprotected op (constraint: copied Constraint; 
keysAndValues : Object ... 
20 /* k ey: keyClass; value: valueClass */) 

throws KeyDuplicated, Keylnvalid, 
Ob j ectsUnpaired; 



Makes the responder's items associations between the 
key- value pairs (argument "keysAndValues") and the 
25 responder's "constraint" attribute the constraint 
(argument "constraint") . 

An exception is thrown if two proposed keys are equal 
("KeyDuplicated") , a proposed key is invalid as such 
("Key Invalid") , or the number of objects is odd 
50 30 ( "Ob j ectsUnpaired" ) . 
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Adaptations 
add 

Only a key satisfying the constraint will be 
included. 

5 constraint 

The constraint is upon the keys. 

include 

Only a key satisfying the constraint will be 
included. 

10 rekey 

Only a key satisfying the constraint will be 
included. 

set 

Only a key satisfying the constraint will be 
15 included. 

4.21 Constrained List: 
Ob j ect (Referenced) 

• Collection 

• • List (Ordered) 

20 • • • Constra ined List (Constrained) 

Class 

ConstrainedList : 

interface (itemClass: Class] 

(List [itemClass], Constrained) = (...); 

25 Parameterized by the class (argument "itemClass") 

which each item of each member of the subject class is 
itself a member. 
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Construction 

initialize : 

5 unprotected op (constraint: copied Constraint; 

items : itemClass . . . ) 
5 throws Itemlnvalid; 

10 Makes the responder's items the objects (argument 

"items"), their positions increasing from left to right, 
and the responder's "constraint" attribute the constraint 

15 (argument "constraint") . 

10 An exception is thrown if a proposed item is invalid 

("Itemlnvalid") . 



20 

Adaptations 



add 

Only an object satisfying the constraint will be 
25 15 included. 

constraint 

The constraint is upon the items . 

30 

include 

Only an object satisfying the constraint will be 
^ 2 0 included. 

4 .22 Constrained Set 
Ob j ect (Referenced) 
40 • Collection 

• • Set (Verified) 
25 • • • Constrained Set (Constrained) 

45 

Class 

ConstrainedSet : 
interface [itemClass : Class] 
50 (Set [itemClass] , Constrained) = (...); 
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Parameterized by the class {argument "itemClass") 
which each item of each member of the subject class is 
itself a member. 

Construction 
5 initialize : 

unprotected op (constraint: copied Constraint ; 
items : itemClass . . . ) 
throws ItemDuplicated, Itemlnvalid; 

Makes the responder's items the objects (argument 
10 "items") and the responder's constraint attribute the 
constraint (argument "constraint") . 

An exception is thrown if two proposed items are 
equal ( " ItemDuplicated" ) or a proposed item is invalid 
such { " Itemlnvalid" ) . 

15 Adaptations 

constraint 

The constraint is upon the items. 
include 

Only an object satisfying the constraint will be 
2 0 included. 

4.23 Constraint 
Object (Referenced) 
• Constraint 

Class 
25 Constrain^ ; 

interface « {...); 

Construction 

initialize : 
unprotected op 
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(classld, passage: Identifier! jNil; 
isOptional , islnstance : Boolean | Nil ) 
t hrows Pas s age I nva lid; 

Makes the responder's "of Class" attribute a nil and 
5 the responder's other native attributes the like-named 
arguments (arguments "classld" , "islnstance", 
"isOptional", and "passage"). If an argument is a nil, 
however, the corresponding attribute is made the 
identifier of class "Object", "false", "false", or 
10 "byRef" , respectively. 

An exception is thrown if the proposed passage is 
invalid as such ( "Pas sage Invalid ") . 

Public Instance Attribute 
c^assl^; 
15 Identifier!; 

The identifier of the class of which the responder's 
subject shall be a member. The identifier is interpreted 
according to the "vocabulary" attribute of the interface 
or implementation that provides the responder's context. 

20 islnstance : 

Boolean; 

Whether the responder's subject shall be an instance, 
not just a member, of the class that the "classld" 
attribute denotes . 

25 isOptional : 

Boolean; 

Whether the responder's subject is permitted to be a 
nil, the "classld" attribute notwithstanding. 



215 



EP 0 634 719 A2 



ofClaas : 

readonly Class | Nil ; 

If not a nil, the class of which the rssponder'i 
subject shall be a member. 

5 passage ; 

Identifier! 

throws Passagelnvalid; 

The identifier denoting how the zesponder's subje 
shall be passed. 

10 An exception is thrown if the proposed passage is 

invalid as such ( "Passagelnvalid* } . 

Adaptation^ 
isEcrual 

Two constraints are equal acceding tc their nati- 
15 attributes. 

4.24 Contact 
Object (Referenced) 
• Contact 

Class 
0 Contact - 

interface = (...); 

Constructi ng 

initially- 

unprotected op (subject; Process j^ril; 
5 subjectNotes: Object |NiI) : 

Makes the responder's "subject" and "subjectNotes" 
attributes the like-named arguments (arguments "subject 
and "subjectNotes", respectively) and -hs responder's 
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other native attributes either descriptive of the subject, 
if the "subject" attribute is a process, or a nil, 
otherwise . 



Public Instance Attributes 
10 5 subject : 

Process (Nil; 



The responder's subject or a nil. 
subiectClass : 

readonly protected Citation | Nil; 

Either the assigned citation of the class, which is a 
subclass of class "Agent" or class "Place", of which the 
responder's subject is an instance, if the "subject" 
attribute is a process, or either that class or a nil, if 
the "subject" attribute is a nil. 



15 subiectName: 

readonly protected Telename (Nil ; 

Either the assigned telename of the responder's 
35 subject, if the "subject" attribute is a process, [or that 

telename] or a nil, otherwise. 

20 subi ectNotes : 

40 Object | Nil; 



An object maintained by the responder's observer. 

45 

Adaptations 
isEcrual 

25 Two contacts are equal according to their 

50 "subjectName" attributes. 
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4.25 Contacted 
Contacted 

Class 

Contacted : 
5 abstract interface () = (...); 

Cons t rue t ion 

initialize 

Clears the responder's "contacts" attribute. 

Private Ins tance Attributes 
10 contacts : 

readonly Set [Contact] ; 

The set of contacts that the responder maintains. 

4.26 Dictionary 
Obj ect (Referenced) 
15 • Collection 
- • • Set 
• • • Dictionar-y 

. Class 

Dictionary: 

20 interface [keyClass, valueClass: Class] 

(Set [Association [keyClass, valueClass]]) a 

<-■.); 

Parameterized by the classes of which the key 
(argument "keyClass") and the value (argument 
25 "valueClass") of each item of each member of the subject 
class are themselves members. 

Construction 

initialize : 
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unprotected op (JceysAndValues : Object ... 

/* key: keyClass; value: valueClass */) 
throws KeyDuplicated, Keylnvalid, 
ObjectsUnpaired; 

5 Makes the responder' s items associations between the 

key-value pairs (argument "keysAndValues" ) . 

An exception is thrown if two proposed keys are equal 
("KeyDuplicated"), a proposed key is invalid as such 
("Keylnvalid"), or the number of objects is odd 
L0 ("ObjectsUnpaired") . 

Public Instance Operations 
add: 

unprotected op (key: keyClass; value: valueClass) 
throws Keylnvalid; 

L5 Includes in the responder a new association, one that 

involves the first object (argument "key") as the 
associations' key and the second (argument "value") as the 
association's value. 

An exception is thrown if the proposed key is invalid 

!0 as such or equals the key in an association that the 
responder already includes ("Keylnvalid") . 

forpp: 



5 



unprotected op (key: protected keyClass) valueClass 
throws Keylnvalid; 

Excludes from the responder and discards the 
association whose key equals the object (argument "key") , 
and returns the association's value. An exception is 
thrown if the asserted key is invalid as such 
("Keylnvalid") . 

find: 
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op (value: protected valueClass) keyClass |Nil ; 

Leaves in the responder the association whose value 
equals the object (argument "value"), and returns the 
association's key. If the responder includes several such 
5 associations, the one selected is undefined. If the 
responder includes none, a nil is returned. 



10 



op (key: protected keyClass) valueClass 
throws Key Invalid; 

Leaves in the responder the association whose key 
equals the object (argument "key"), and returns the 
association's value. 

An exception is thrown if the asserted key is invalid 
as such ("Keylnvalid") . 

15 rekey : 

unprotected op (currentKey: protected keyClass; 

newKey: keyClass) 
throws Keylnvalid; 

Leaves in the responder the association whose key 
20 equals the first object (argument "currentKey"), discards 
that association's key, and substitutes for that key the 
second object (argument "newKey") . The operation achieves 
this as if by means of operations "drop" and "add" . 

An exception is thrown if the asserted or proposed 
25 key is invalid as such or the latter equals the key in an 
association that the responder already includes 
("Keylnvalid") . 



set : 



unprotected op (key: protected keyClass; value: 
3 0 valueClass) 
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throws Key Invalid; 

5 

If the responder includes an association whose key 
equals the first object (argument "key"), substitutes for 
chat association's value the second object (argument 
10 5 "value") . Otherwise, includes in the responder a new 

association, one that involves the first object (argument 
"key") as the association's key and the second (argument 
"value") as the association's value. 

15 

An exception is thrown if the proposed key is invalid 
10 as such ("Keylnvalid") . 



20 transpose : 

unprotected op (keyl, key2 : protected keyClass) 
throws Key Invalid; 



25 
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Transposes the responder' s values for the two keys 
15 (arguments "keyl* 1 and "key2" ) . 

An exception is thrown if an asserted key is invalid 
as such ( " Key Inval id " ) . 



Adaptations 

include 

35 20 Only an association is included. An association is 

included as a new item after excluding and discarding any 
existing item equal to the association . 



isEoual 

Two dictionaries are equal only if their like-keyed 
2 5 values are equal. 

4.27 Exception 

Ob j ec t ( Re f er enced ) 

• Exception (Unchanged) 

Class 
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Exception: 

abstract interface (Object, Unchanged) = (...); 

Public Inst ance Operations 
throw: 
5 sealed op {) ; 

Finishes the current method's performance by causing 
the method to fail because of the responder. 



Adaptations 
isEaual 

20 10 T* 0 exceptions are equal iff they are instances of 

the same class. 



4,28 Executed 
Executed 

Class 
15 Executed;: 

abstract interface () = () ; 

This class is sealed. 



Public Instan ce Operations 
catch: 

20 sealed op (exception: Class) Exception) Nil 

40 throws Exception; 

Performs the responder, returning either a nil, if 
the responder succeeds, or the exception causing the 
responder to fail, if the exception is a member of the 
25 supplied class (argument "exception"). The responder gets 
access to the requester's frame and properties, rather 
than the responder' s. 



so 
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An exception is thrown if the responder throws an 
exception that is not a member of the supplied class 
( "Exception" ) . 

Note : The class should be Exception or a subclass 

5 thereof. 

do : 

sealed op () 

throws Exception; 

Performs the responder. The responder gets access tc 
10 the requester's frame and properties, rather than the 
responder' s. 

An exception is thrown if the responder does so 
( "Exception" ) . 

25 either: 

15 sealed op (false: Executed; precondition: Boolean) 

throws Except ion ; 
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Performs either the responder, if the precondition 
(argument "precondition") is true, or the executed object 
(argument "false"), otherwise. The selected executed 
20 object gets access to the requester's frame and 
properties, not the responder' s. 

An exception is thrown if the selected executed 
object does so ("Exception"). 



2J 

2 5 sealed op (precondition: Boolean) 

throws Exception; 



50 



Performs the responder iff the precondition (argument 
"precondition") is "true". The responder gets access to 
the requester's frame and properties, not its own. 
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An exception is thrown if the responder does so 
("Exception") . 

loop: 

sealed op () 
5 throws Exception; 

Performs the responder an indefinite number of times, 
throwing the exception, rather than proceeding, if the 
responder ever fails. The responder gets access to the 
requester's frame and properties, rather than the 
1 0 responder ' s . 

An exception is thrown if the responder does so 
("Exception") . 

repeat : 

sealed op (repetitions: Integer) 
15 throws Exception; 

Performs the responder the requested number of times 
(argument "repetitions" ) , throwing the exception, rather 
than proceeding, if the responder ever fails. If the 
integer is negative, the operation has no effect. The 
20 responder gets access to the requester's frame and 
properties, rather than the responder' s. 

Before each performance of the responder, the 
operation pushes onto the stack an integer that is one 
plus the number of prior performances. 
25 An exception is thrown if the responder does so 

( "Exception") . 

Na£e: The operation pops none of the integers the 

operation pushes onto the stack. 

while : 

30 sealed op (precondition: Executed) 

throws Exception, Result Invalid, ResultMissing; 
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Repeatedly performs the executed object (argument 
"precondition") , pops a boolean from the stack, and, iff 
the boolean is true, performs the responder. If the 
boolean is ever false, the operation succeeds. If either 
5 executed object ever fails, the operation throws the 

exception, rather than proceed. The executed objects are 
given access to the requester's frame and properties, 
rather than the responder' s. 

An exception is thrown if either executed object does 
10 so ("Exception"), the object that would have been popped 
is not a boolean ( "Resultlnvalid" ) , or there is no object 
on the stack to be popped then ( "ResultMissing" ) . 

4.29 Execution Exception 
Ob j ect (Referenced) 
15 • Exception (Unchanged) 

• • Programming Exception 

• • • Kernel Exception 

• • • • Execution Exception 

20 Executi onException : 

abstract interface (KernelException) = () ; 

Subclasses 

Argument Inval id ; 

interface (ExecutionException) = {) ; 

25 An argument does not satisfy the argument's 

constraint . 

AroumentMissincr : 

interface (ExecutionException) = () ; 
An argument is not on the stack. 
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At tributeReadOnly - 

interface (ExecutionException) s () ; 

An attribute is read-only, and thus cannot be set 

10 ClassUnavailable : 

5 interface (ExecutionException) = () ; 



15 



A class is in neither attribute "privateClasses" of 
the current process nor attribute "publicClasses " of the 
current place, 

20 Escalatiohlnvalid : 

10 interface (ExecutionException) - () ; 



A feature is escalated improperly. 
FeatureUnavailable : 

interface (ExecutionException) » () ; 

An identifier does not denote an accessible feature 
15 of the responder. 

Internal Exceotion « 
interface (ExecutionException) = () ; 

40 An Engine fails to fully implement the Instruction 

Set . 
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20 PropertvUnde fined - 

interface (ExecutionException) = () ; 



An identifier does not denote a property accessible 
so to the current method. 

ReferenceProtectfiH ■ 
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interface (ExecutionException) = () ; 

A reference to an object prevents the object's 
modification . 

Ref erenceVoid : 
5 interface (ExecutionException) = () ; 

A reference is void. 

ResoonderMissinq : 

interface (ExecutionException) = () ,* 

A feature is requested when the stack is cleared. 

10 Result Invalid: 

interface (ExecutionException) « () ; 

A result does not satisfy the result's constraint. 
ResultMissina : 

interface (ExecutionException) = () ; 
15 A result is not on the stack. 

VariableUndef ined : 

interface (ExecutionException) « () ; 

An identifier does not denote a variable. 

4 .30 Feature 
20 Object (Referenced) 
• Feature 

Class 

Feature : 
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abstract interface = (...); 

This class is sealed. 

Construction 

initialize : 
5 unprotected op ( 

isPublic: Boolean | Nil; 
is exceptions: Set [Identif ier !] |Nil) ; 

Makes the responder's native attributes the 
like-named arguments (arguments "exceptions" and 
10 "isPublic"). if an argument is a nil, however, the 
corresponding attribute is cleared or made "false" , 
respectively . 



20 
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Public Instance Attribute 
exceptions ; 
15 Set [Identifier!]; 

The identifiers denoting the classes of which the 
exceptions thrown by the feature the responder defines are 
members. The identifiers are interpreted according to the 
"vocabulary" attribute of the interface that includes the 
20 responder. 

isPublic; 
Boolean ; 

Whether the feature that the responder defines is 
public, i.e., not private. 

25 4.31 Hashed 
Hashed 
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Class 

Hashed : 

abstract interface {) = (...); 

Public Instance Attributes 
5 hash : 

abstract readonly Integer; 

The responder's hash. 

4-32 Identifier 
Ob j e c t ( Re f er enced ) 
10 • Primitive (Executed & Unchanged) 
• • Identifier (Ordered) 

Class 

Identifier : 

sealed interface (Primitive, Ordered) - () ; 
15 Adaptations 

isMter 

One identifier is after another according to 
their texts. 

isBefore 

20 One identifier is before another according to their 

texts . 

isEoual 

Two identifiers are equal according to their texts. 
Conversions 

25 String 

A string that is valid as an identifier's text 
produces that identifier . 
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4.33 Implementation 
Ob j ect ( Referenced) 
• Implementation 

Class 

5 implementation : 

sealed interface » (...); 

Construction 

initialize : 

unprotected op {superclasses: List [Identif ier ! ] j Nil ; 
10 vocabulary: Lexicon [Citation] |Nil; 

properties: List [Identifier!] |Nil; 

instanceMethods , setMethods , classMethods , 

f romMethods, toMethods : Lexicon [Method] | Nil) ; 

Makes the responder's native attributes the 
15 like-named arguments (arguments "classMethods 11 , 
"f romMethods" , "instanceMethods" , "properties" , 
"setMethods", "superclasses", "toMethods", and 
"vocabulary"). If an argument is a nil but the 
corresponding attribute is not permitted to be a nil, 
20 however, the corresponding attribute is cleared. 

Public Instance Attributes 
classMethods ; 
Lexicon [Method] ; 

Methods — for class operations, including operation 
25 "aGet", other than operation "aSet" which is 

disallowed- -native to a class incorporating the responder. 
Each value is a method for performing the operation the 
associated key denotes . 

f romMethods : 
30 Lexicon [Method] ; 
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Methods- -for converting from other classes- -native to 
a class incorporating the responder. Each value is a 
method for converting from the class the associated key- 
denotes . 

5 Note : In an implementation of class "Dictionary" , if 

the class identified is class "List", the 
conversion is that whose responder is class 
"Dictionary" and whose signature is "List: op 
(list: protected List) Dictionary". 

10 instanceMethods : 

Lexicon [Method] ; 

Methods- -for instance operations, including operation 
n <xGet n , other than operation n aSet n (see attribute 
"setMethods") --native to a class incorporating the 
15 responder. Each value is a method for performing the 
operation the associated key denotes. 

properties: 

List [Identifier!] ; 

The identifiers of properties native to a class 
2 0 incorporating the responder. Their order has no 
significance in the interpretation of the disclosed 
instruction set. However, the order of the properties is 
significant in the Encoding Rules disclosed in Appendix B 
of this disclosure. 

25 setMethods : 

Lexicon [Method] ; 

Methods- -for "aSet" instance operations- -native to a 
class incorporating the responder. Each value is a method 
for performing the operation the associated key denotes. 
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superclasses ? 

List [Identifier!] |Nil; 

Either the identifiers of the implementation 
immediate superclasses of a class incorporating the 
5 responder, if they differ from the class' interface 

immediate superclasses, or a nil, otherwise. The classes' 
canonical order is that of their identifiers; the last 
class shall be a flavor. 

toMethods : 
10 Lexicon (Method] ; 

Methods--for converting to other classes-native to a 
class incorporating the responder. Each value is a method 
for converting to the class the associated key denotes. 
Note.: m an implementation of class "Dictionary"/ if 

15 th ^ class identified is class "List", the 

conversion is that whose responder is a 
dictionary and whose signature is "List: op () 
List" . 

vocabulary, 
20 Lexicon [Citation] |Nil; 

Either the user-defined classes to which the 
responder refers, if they are not those to which the 
class' interface refers, or a nil, otherwise. Each value 
is a citation to the class the associated key denotes. 
25 The attribute guides the interpretation of the responder' s 
"fromMethods", "superclasses", and "toMethods" attributes 
(and no others) . 

Adaptations 
isEerual 
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Two implementations are equal according to their 
native attributes . 

4 . 34 Integer 
Ob j ect (Referenced) 
5 • Primitive (Executed & Unchanged) 

• • Number (Ordered) 

• • • Integer 

Class 

Integer: 

10 sealed interface (Number) = (...); 

Public Instance Operations 
modulus : 

op (divisor: Integer) Integer 
throws DivisionByZero; 

15 Returns the arithmetic remainder of the responder, 

the dividend, and the integer (argument "divisor") , the 
divisor. The former's sign determines the result's. 

An exception is thrown if the divisor is zero 
("DivisionByZero") . 

20 guotient : 

op (divisor: Integer) Integer 
throws DivisionByZero ; 

Returns the arithmetic quotient of the responder, the 
dividend, and the integer (argument "divisor"), the 
25 divisor. 

An exception is thrown if the divisor is zero 
("DivisionByZero") . 



so 
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Adaptations 

The result is an integer. 
add 

5 The result is a real if the argument is a real, an 

integer if an integer. 

divide 

The result is a real if the argument is a real, an 
integer if the argument is an integer and the result would 
10 be exact, and a real, otherwise. 

multiply 

Same as described above for operation "add" . 
negate 

The result is an integer. 

15 subtract 

Same as described above for operation "add" . 

Conversions 
Bit 

The bits "zero" and "one" produce zero and one, 
20 respectively. 

BitStrino 

A bit string that can be produced by converting some 
integer produces the integer. 

Boolean 

25 The booleans "false" and "true" produce zero and one, 

respectively. 

Character 
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A character produces the integer in [0, 6553 5] that 
is the character's Unicode code. 

Octet 

An octet produces the result of first converting the 
5 octet to an octet string, and then converting the octet 
string to an integer. 

QctetStrina 

An octet string that can be produced by converting 
some integer produces the integer. 

10 Real 

A real produces the integer that results from 
performing operation "truncate". 

String 

A string that obeys the syntactic rules for the 
15 "Integer" token in Character Telescript produces the 
corresponding integer. 

4.35 Interchanged 

Unchanged 

• Interchanged 

20 Class 

Interchanged : 

abstract interface (Unchanged) = (...); 

Public Instance Attributes 
digest : 

25 abstract readonly protected Object | Nil ; 

Either the digest of the responder, if the responder, 
i.e., this particular instance of the class, is 
interchangeable, or a nil, otherwise. 
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4.36 Interface 

Ob j ec t (Re f erenced ) 

• Interface 

Class 
5 Interface : 

sealed interface = (...); 

Construction 

initialize; 

unprotected op (superclasses: List [Identif ier I ] j Nil ; 
10 vocabulary: Lexicon [Citation] |Nil; 

instanceFeatures: Lexicon [Feature] (Nil; 

sealedlnstanceFeatures : Set [Identifier!] |Nil; 

classFeatures ; Lexicon [Feature] |Nil; 

sealedClassFeatures: Set [Identifier!] |Nil; 
15 isAbstract: Boolean } Nil ) ; 

Makes the responded s native attributes the 
like-named arguments (arguments "classFeatures", 
» instanceFeatures " , « isAbstract » , » sealedClassFeatures " , 
"sealedlnstanceFeatures", "superclasses", and 

20 "vocabulary"). if the corresponding argument is a nil, 

however, attribute "isAbstract" is made "false", attribute 
"superclasses" is made a list of the identifier of class 
"Object" alone, or the attribute is cleared if the 
attribute is other than attribrutes "isAbstract" and 

25 " superclasses " . 

Public Insta nce AttrihnhPQ 
classFeatures ; 
Lexicon [Feature] ; 

The class features native to a class incorporating 
30 the responder. Each value is the feature definition of 
the feature the associated key denotes. 
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instanceFeatures : 
Lexicon [Feature] ; 

The instance features native to a class incorporating 
the responder. Each value is the feature definition of 
5 the feature the associated key denotes. 

isAbstract : 
Boolean ; 

Whether a class incorporating the responder is 
abstract . 

-0 sealedClassFeatures : 

Set [Identifier!] ; 

The identifiers of the class features that are either 
native to or inherited by a class incorporating the 
responder, and that are sealed by that class. 

5 sealedlnstanceFeaturea : 

Set [Identifier!] ; 

The identifiers of the instance features that are 
either native to or inherited by a class incorporating the 
responder, and that are sealed by that class* 

0 superclasses: 

List [Identifier!] ; 

The identifiers of the interface immediate 
superclasses of a class incorporating the responder. The 
classes' canonical order is that of their identifiers; the 
5 last class shall be a flavor. 

vocabulary: 
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Lexicon [Citation] ; 

The user-defined classes to which the responder 
refers- Each value is a citation to the class the 
associated key denotes. The attribute guides the 
5 interpretation of the responder' s "superclasses" 
attribute and no others. 

Adapt at ions 
isEqual 

Two interfaces are equal according to their native 
10 attributes. 

4-37 Kernel Exception 
Ob j ect (Referenced) 

• Exception (Unchanged) 

• • Programming Exception 
15 • • • Kernel Exception 

Class 

KernelExceptii * 

abstract interface (ProgrammingException) = () ; 

Subclasses 
20 ClassAbstract : 

interface (KernelException) = () ; 

An object's proposed class is abstract. 



Conver s ionUnavai labl : 
45 interface (KernelException) () 

25 An object's proposed conversion is undefined. 



CopvUn available « 

interface (KernelException) = () ; 
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An object's property cannot be copied. 
liOQpMi s s inq : 

interface ( Kerne lExcept ion) = {) ; 

A loop is broken or continued where no loop exists. 

5 MarkMissino: 

interface (Kerne lExcept ion) = () ; 

A stack's items do not include a mark. 

ObiectUninitialized: 

interface (KernelException) « (); 

10 An object attempts to use one of its features before 

escalating operation "initialize". 

Passaaelnvalid: 

interface (KernelException) - (} ; 

An object's proposed passage is invalid. 

15 SelectorDuplicated ; 

interface (KernelException) « () ; 

Two selectors are equal . 

4 . 38 Lexicon 

Obj ect (Referenced) 



20 



Collection 

• Set 

• • Dictionary 

• • • Constrained Dictionary (Constrained) 

• • • • Lexicon 
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35 



Class 

Lexicon : 

interface [valueClass : Class] 

(ConstrainedDictionary [Identifier, valueClass] ) 
=(...); 

Parameterized by the class (argument "valueClass") of 
which the value of each item of each member of the subject 
class is itself a member. 



Construction 
10 initialize : 

20 unprotected op (keysAndValues: Object ... 

/* key: Identifier!; value: valueClass */) 
throws KeyDuplicated, Keylnvalid, 
ObjectsUnpaired; 



15 Makes the responder's items associations between the 

key- value pairs (argument "keysAndValues"). 

An exception is thrown if two proposed keys are equal 
("KeyDuplicated") , a proposed key is invalid as such 
("Keylnvalid") , or the number of objects is odd 

2 0 ( "ObjectsUnpaired" ) . 



Adaptations 

constraint 

The attribute is sealed. The attributes "ofClass", 
m "classld", "islnstance", » isOptional " , and "passage" 

25 attributes are class "Identifier", the identifier of class 
"Identifier-, "true", -false", and "byCopy" , respectively. 

45 Conversion a 

Dictionary 

A dictionary whose keys satisfy the constraints of a 
3 0 lexicon produces the lexicon. 

so 
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4,39 List 

Ob j ect ( Referenced) 

• Collection 

• • List (Ordered) 



10 5 Class 

List;: 



15 



20 



interface [itemClass: Class] 

(Collection [itemClass] , Ordered) = (...); 

Parameterized by the class (argument "itemClass") of 
10 which each item of each member of the subject class is 
itself a member. 



Con s t rue t i on 

initialize : 

unprotected op (items: itemClass ...); 



15 Makes the responder's items the objects (argument 

"items"), whose positions increase from left to right. 

30 

Public Instance Operations 
add: 

35 unprotected op (position: Integer; item: itemClass) 

20 throws Itemlnvalid, Positionlnvalid; 



Includes the object (argument "item") in the 
responder as a new item, one whose position equals the 
integer (argument "position"), increasing by one the 
position of each item whose position is equal to or after 
25 that of the included item. 

An exception is thrown if the proposed item is 
invalid as such ("Itemlnvalid") or the proposed position 
is invalid as such ("Positionlnvalid"). 

drop : 
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unprotected op (position: Integer) itemClass 
throws Positionlnvalid; 

Excludes from the responder and returns the item 
whose position equals the integer (argument "position"), 
5 decreasing by one the position of each item whose position 
is after that of the excluded item. 

An exception is thrown if the asserted position is 
invalid as such ("Positionlnvalid") . 

find: 



10 op (initialPosition: Integer; item: protected 

itemClass) 

Integer | Nil 
throws Positionlnvalid; 

25 Leaves in the responder and returns the position of 

15 the item that equals the object ("item") and whose 

position is not before the integer ("initialPosition") . 
If the responder has several such items, the one whose 
position is least is selected. If it has none, a nil is 
returned . 

An exception is thrown if the asserted position is 
invalid as such ("Positionlnvalid"). 



20 



get : 

op (position: Integer) itemClass 
40 throws Positionlnvalid; 

2 5 Leaves in the responder and returns the item whose 

position equals the integer (argument "position") . 

An exception is thrown if the asserted position is 
invalid as such ("Positionlnvalid"). 



reposition : 
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unprotected op (currentPosition, newPosition: 
Integer) 

throws Positionlnvalid; 

Changes to the second integer (argument 
5 "newPosition") the position of the responder's item whose 
position equals the first integer (argument 
"currentPosition"). The operation achieves this as if by 
means of operations "drop" and "add", except that the 
second integer is interpreted before, rather than after, 
10 operation "drop" is requested. 

An exception is thrown if an asserted position is 
invalid as such ( "Positionlnvalid" ) . 

set : 

unprotected op (position: Integer; item; itemClass) 
15 throws Itemlnvalid, Positionlnvalid; 

Excludes from the responder the item, if there is 
one, i.e., if the new item is not being appended, whose 
position equals the integer (argument "position"), and 
includes the object (argument "item") as a new item at the 
20 same position. 

An exception is thrown if the proposed item is 
invalid as such ("Itemlnvalid") or the proposed position 
is invalid as such ("Positionlnvalid") . 

transpose : 

25 unprotected op (positionl, position2 : Integer) 

throws Positionlnvalid; 

Transposes the responder's items that occupy the two 
positions (arguments "positionl" and "position2 " ) . 

An exception is thrown if an asserted position is 
30 invalid as such ("Positionlnvalid") . 
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Adaptations 
exclude 

The operation decreases by one the position of each 
object whose position is after that of the excluded item. 

5 include 

The position of the newly included item is the list's 
new length. 

is Equal 

Two lists are equal only if their like -positioned 
10 items are equal . 

stream 

The stream produces the list's items in order of 
increasing position. 

Conversions 
15 Procedure 

A procedure produces a list of the same length, each 
of whose items is a copy of the item at the same position 
in the procedure. 

4.40 Mark 
20 Object (Referenced) 

• Primitive (Executed & Unchanged) 

• • Mark 

Class 

Mark: 

25 sealed interface (Primitive) = () ; 

Adaotat ions 
isEoual 

Any two marks are equal . 
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4.41 Means 

Ob j ect (Referenced) 

• Means 



Class 
5 Means : 

abstract interface = (); 

4.42 Meeting Exception 
Object (Referenced) 
• Exception (Unchanged) 
10 • • Meeting Exception 

Class 

MeetingException : 

abstract interface (Exception) = () 

Subclasses 
15 Meet ingDenied : 

interface (MeetingException) = (} ; 

The petitionee denies the petitioner the meeting. 
Meet ingDupl icat ed r 

interface (MeetingException) = (); 

2 0 The petitioner and petitionee are the same or meeting 

already. 



Meetinglnvalid; 

interface (MeetingException) = () ; 

A contact does not represent a meeting. 

25 Petitio nExpired * 

interface (MeetingException) = (); 
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The petitionee cannot be met in the time allowed. 

5 4.43 Meeting Place 

Object (Referenced) 

• Process (Named) 

5 • • Place (Unmoved) 

10 

• • • Meeting Place 



Class 

15 MeetingPlace : 

abstract interface (Place) » (...); 



20 



10 Public Instance Operations 
meet: 



unprotected op (petition: copied Petition) Contact 
throws Meet ingExcept ion, ProcessNot Current, 
25 Statelmproper; 



15 Begins a meeting between the agent requesting the 

operation and the one the petition (argument "petition") 

30 

identifies, returning a contact whose "subject" attribute 
is the latter. The latter agent must also occupy the 
responder. 

35 20 An exception is thrown if the meeting failed 

( "Meet ingExcept ion" ) , the responder is not the current 
place ( " ProcessNotCurrent '» ) , or the requester's state 
precludes "meet" ("Statelmproper") . 

40 

part : 

25 unprotected op (contact: Contact) 

throws Meetinglnvalid, ProcessNotCurrent, 
Statelmproper ; 



Ends the meeting between the agent requesting the 
operation and the subject of the contact (argument 
30 "contact"), making the contact's "subject" attribute a 
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nil, if the attribute is not a nil already. The subject 
must also occupy the responder. 

An exception is thrown if the contact is not a 
meeting's ( "Meetinglnvalid" ) , the responder is not the 
5 current place ( "ProcessNo t Current " ) , or the requester's 
state precludes operation "part" ( "State Improper ") . 

partAll : 

unprotected op () 

throws ProcessNotCurrent , State Improper ; 

10 Ends all meetings that involve the requesting agent, 

and then isolates the agent. 

An exception is thrown if the responder is not the 
current place ("ProcessNotCurrent") or the requester's 
state precludes operation "partAll" ( "State Improper 11 ) . 

15 4.44 Method 

Ob j ect (Referenced) 
• Method 

Class 

Method: 

20 sealed interface « (-..); 

Cons t rue t i on 

initialize : 

unprotected op (procedure: Procedure | Nil ; 
variables: List [Identif ier ! ] | Nil) ; 

25 Makes the responder' s native attributes the 

like -named arguments (arguments "procedure" and 
"variables") . If an argument is a nil, however, the 
corresponding attribute is cleared. 

Public Instance Afctrihni-^ 
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procedure - 
Procedure ; 

The responder's procedure. 

variables : 
5 List [Identifier!] ; 

The identifiers of the responder's variables, their 
order having no significance with respect to the 
interpretation of the disclosed instruction set. However, 
the order of the variables is significant in the Encoding 
10 Rules described in Appendix B of this disclosure. 

Adaptations 
isEoual 

Two methods are equal according to their native 
attributes . 

15 4.45 Miscellaneous E xception 
Ob j ect (Referenced) 

• Exception (Unchanged) 

• • Programming Exception 

• • • Miscellaneous Exception 

20 Class 

Miscellaneo usExcep t-icvn • 

abstract interface (ProgrammingException) = () ; 

Subclasses 

PatternTnval 

25 interface (MiscellaneousException) = {) ; 

A pattern's proposed text is syntactically in error. 
Seedlnval id - 
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interface (MiscellaneousException) = {); 

A random stream's proposed seed is not in the 
required range. 

4 .46 Modifier 
5 Object (Referenced) 

• Primitive (Executed & Unchanged) 

• • Modifier 

Class 

Modifier : 

10 sealed interface (Primitive) = (); 

Adaptations 
isEcrual 

Two modifiers are equal iff their values are the 

same . 

15 4.47 Named 
Named 

Class 

Named : 

abstract interface () = (...); 

20 Construction 

initialize 

Makes the responder's "name" attribute a newly 
assigned telename, a peer of the current process'. 

Public Inst ance Atcributeg 
25 name: 

sealed readonly protected Telename; 
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The responder's assigned telename. 
4.48 Nil 

Ob j ect (Referenced) 

• Primitive (Executed & Unchanged) 
5 • • Nil 

Class 

Nil : 



sealed interface (Primitive) = () ; 

Adaptations 
10 isEoual 

Any two nils are equal. 

4.49 Number 

Ob j ect (Referenced) 

• Primitive (Executed & Unchanged) 
15 • • Number (Ordered) 

Class 

Number : 

abstract interface (Primitive, Ordered) = ( 

This class is sealed. 

20 Public Instance Operations 
abs: 

abstract op () Number; 

Returns the absolute value of the responder. 
add: 

25 abstract op (number: Number) Number 
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Returns the arithmetic sura of the number ("number 1 ') 
and the responder . 

ceiling: 

abstract op () Integer; 

5 Returns the smallest integer that is arithmetically 

greater than or equal to the responder. 

divide : 

abstract op (divisor: Number) Number 
throws DivisionByZero; 

10 Returns the arithmetic quotient of the responder, the 

dividend, and the number (argument "divisor"), the 
divisor. 

An exception is thrown if the divisor is zero 
("DivisionByZero") . 

15 floor: 

abstract op () Integer; 

Returns the largest integer that is arithmetically 
less than or equal to the responder. 

multiply: 

20 abstract op (number: Number) Number ; 

Returns the arithmetic product of the number 
("number") and the responder. 

negate : 

abstract op () Number ; 
25 Returns the arithmetic negative of the responder. 
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round: 

abstract op () Integer ; 

Returns the single integer that is, or one of the two 
integers that are, arithmetically nearest to the 
5 responder . 

subtract : 

abstract op (subtrahend: Number) Number ; 

Returns the arithmetic difference between the 
responder, the minuend, and the number (argument 
10 "subtrahend"), the subtrahend. 

truncate : 

abstract op () Integer; 

Returns the integer formed by discarding the 
responder' s fractional part so as to arithmetically 
15 truncate the responder toward zero. 

Adaptations 
isAf ter 

One number is after another iff the first is greater 
than the second. 

0 isBefore 

One number is before another iff the first is less 
than the second. 

isEqual 

Two numbers are equal iff they are equal 
5 mathematically. 

4.50 Object 

Object (Referenced) 
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Class 

Object: 

abstract interface (Referenced) = (...); 

Construction 
5 initialize : 

unprotected op () ; 

Initializes the responder, a potential object, and 
makes the responder an object. 

finalize : 
10 unprotected op () ; 

Requested as the responder is destroyed by operation 
"discard". A method for this operation finalizes the 
object with respect to the method's class . 

Public Instance Attrihufpg 
15 class : 

sealed readonly Class; 

Either the class of which the responder is an 
instance, if the responder is not class "Class", or class 
"Class", if the responder is indeed class "Class". 

20 size: 

sealed readonly Integer ; 

The responder' s size in octets, i.e., the approximate 
amount of storage that destroying the responder would 
reclaim. 

25 Public Instance Operations 
copy: 

sealed op () copied Object 
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throws CopyUnavailable; 

Returns either the responder, if the operation is 
requested using the only reference to the responder, or a 
copy of the responder, otherwise. 
5 An exception is thrown if a copy if unavailable 

("CopyUnavailable") . 

isEoual : 

op (object; protected Object) Boolean ; 

Returns an indication of whether the object (argument 
10 "object") equals the responder. 

A method shall escalate this operation if either the 
responder or the object is not a member of the class to 
which the method is native. The method native to class 
"Object" deems the two equal iff they are the same object. 

15 Select : 

sealed op (associations: Object ... 

/* protected Object; Executed */) 
throws Exception, SelectorDuplicated; 

From the pairs of objects and executed objects 
20 (arguments "associations") , selects and performs at most 
one executed object. The one selected gets access to the 
requester's frame and properties, not the responder' s. 

If an object equals the responder, the executed 
object paired with that object is selected. Otherwise, if 
25 any object is a nil, the executed object paired with that 
object is selected. Otherwise, no executed object is 
selected. 

An exception is thrown if the selected executed 
object does so ("Exception") or two objects paired with 
30 executed objects are equal ("SelectorDuplicated"). 
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Internal Instance Operations 
aetAttribute : 

sealed op (identifier: Identifier) Object 

throws ClassUnavailable , FeatureUnavailable ; 

5 Returns the responder' s attribute denoted by the 

identifier (argument "identifier"). The attribute follows 
the passage prescribed for the attribute. 

An exception is thrown if the class the identifier's 
qualifier denotes is absent ("ClassUnavailable") or the 
10 identifier denotes no attribute of the responder that is 
accessible to the requester ("FeatureUnavailable") . 

qetglagig; 

sealed private op (identifier: Identifier!) Class 
throws ClassUnavailable; 

15 Returns the class the identifier (argument 

"identifier") denotes to the current method. 

An exception is thrown if the class is absent 
("ClassUnavailable") . 



20 



ge t Prope r t v : 

sealed private op (identifier: Identifier!) Object 
throws Prope rtyUnde fined; 



Returns the responder' s property that is both denoted 
by the identifier (argument "identifier") and native to 
the class to which the current method is native. The 
25 returned reference is protected iff the responder is 
protected. 

An exception is thrown if the identifier is invalid 
( " Proper tyUndef ined " ) . 

qetVariable : 

30 sealed private op (identifier: Identifier!) Object 
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throws VariableUnde fined; 

Returns the current method's variable the identifier 
(argument "identifier") denotes. 

An exception is thrown if the identifier is invalid 
5 ("VariableUndefined") . 

setAttribute : 

sealed unprotected op (identifier: Identifier ; 

attribute: Object) 
throws Argument Invalid, AttributeReadOnly, 
■0 ClassUnavailable, FeatureUnavailable ; 

Makes the object (argument "attribute") the 
responder's attribute denoted by the identifier (argument 
"identifier") . The operation first discards the attribute 
if it exists. The object follows the passage prescribed 

5 for the attribute. 

An exception is thrown if the object violates the 
attribute's constraint ( "Argument Invalid ") , the attribute 
is read-only ( "AttributeReadOnly" ) , the class the 
identifier's qualifier denotes is absent 

0 ("ClassUnavailable") , or the identifier denotes no 
attribute of the responder that is accessible to the 
requester ("FeatureUnavailable") . 

setPropertv: 

sealed private unprotected op (identifier: 
5 Identifiers- 
property: Object) 
throws PropertyUndef ined; 

Makes the object (argument "property") the 
responder' s property that is both denoted by the 
0 identifier (argument "identifier") and native to the class 
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to which the current method is native. The operation 

first discards the property if the property exists. 

An exception is thrown if the identifier is invalid 
( "PropertyUndef ined" ) . 

setVariable : 

sealed private unprotected op (identifier: 
Identifier ! ; 

variable: Object) 
throws VariableUndef ined; 



10 Makes the object (argument "variable") the current 

20 method's variable the identifier (argument "identifier") 

denotes. The operation first discards the variable if the 
variable exists . 

An exception is thrown if the identifier is invalid 
15 ( "VariableUndef ined" ) . 



4.51 Q<?t;et 
Ob j ect (Referenced) 

• Primitive (Executed & Unchanged) 

• • Octet (Ordered) 

35 20 Cl^ss 

Octet : 

sealed interface (Primitive, Ordered) = (),- 

40 

Adaptations 
isAf ter 

25 One octet is after another iff two of their 

45 like -numbered bits are unequal and the first octet' 

highest -numbered such bit is after the second's. 
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isBefore 

5 One octet is before another iff two of their 

like -numbered bits are unequal and the first octet's 
highest -numbered such bit is before the second's. 

10 5 isEoual 

Two octets are equal iff neither is before the other. 
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Conversions 
Bit 

A bit produces an octet whose Bit 0 equals the bit 
10 and whose Bits 1-7 are zero. 



Character 

A character whose Unicode code is an integer in [0, 
127] produces the octet that converting that integer 
25 produces . 

15 Integer 

An integer in the range of [-128, 127] produces the 
octet that forms the integer's twos' complement 
representation. Bit 7 represents -128, while Bit "n" 
represents 2°, for each "n" in the range of [0 f 6] . 



20 OctetStrina 

An octet string with one item produces an octet equal 
to that item. 

4 - 52 Octet Strincr 
Object (Referenced) 
25 • Collection 

• • List (Ordered) 

• • • Constrained List (Constrained) 

• • • • Octet String (Executed) 

Class 
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OctetStrina: 

sealed interface (ConstrainedList [Octet] , Executed) 
= (...); 

Cons t rue t ion 
5 initialize : 

unprotected op (segments: Object . . . 

/* Octet [protected OctetString! */) ; 

Makes the responder a concatenation of the segments 
(argument "segments") whose positions in the responder 
10 increase from left to right. 

Adaptations 

constraint 

The attribute is sealed. The attribute's "of Class" , 
"classld", " is Instance n , "isOptional" , and "passage" 
15 attributes are class "Octet ", the identifier of class 
"Octet", "true", "false", and "byCopy" , respectively. 

jgA^ter 

One octet string is after another as if all -zero 
octets were first prepended to the shorter octet string to 
20 make the shorter octet string equal in length to the 
longer octet string. 

isBef ore 

One octet string is before another as if all -zero 
octets were first prepended to the shorter octet string to 
2 5 make the shorter octet string equal in length to the 
longer octet string. 

Conversions 
Bit 



259 



EP 0 634 719 A2 



10 



15 



20 



25 



30 



35 



40 



45 



A bit produces the octet string that results from 
first converting the bit to an octet, and then converting 
the octet to an octet string. 

BitStrina 

5 A bit string whose length is "n" produces an octet 

string whose length is "i». «n" is in the range [8i, 
8i+7] . Bit "j» of the octet at position «k» of the octet 
string either equals the bit at position (8k -j) of the 
bit string, if (8k -j) sn, or is zero, otherwise. 

!0 Character 

A character that can be produced by converting some 
octet string whose length is two produces that octet 
string. 

Integer 

15 An integer in the range [-2 80 - 1 , 2 811 " 1 ) , for an integer 

"n H and none smaller, produces an octet string whose 
length is V. A twos' complement representation is used, 
wherein Bit 7 of the octet whose position is one 
represents -2 8 * 1 , while every other Bit "j" of the octet at 

20 position »i» in the octet string represents 2^^. 

Octet 

An octet produces an octet string whose only item 
equals that octet . 

String 

2 5 A string produces a "characters" token for encoding 

the string in a binary telescript. 



4.53 Operation 
Ob j ect ( Referenced) 
50 • Feature 

30 • • Operation 
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Class 

Operation: 

sealed interface (Feature) = (...); 

Construction 
5 initialize: 

unprotected op (arguments: List [Constraint] | Nil ; 
result : Constraint j Nil ; 
isPublic : Boolean jNil; 
exceptions; Set [Identif ier ! ] |Nil) ; 

10 Makes the responder's attributes the like-named 

arguments (arguments "arguments" , "exceptions", 
"isPublic", and "result"). If argument "exceptions" or 
argument "isPublic" is a nil, however, the corresponding 
attribute is cleared or made "false", respectively. 

15 Public Instance Attributes 
arguments : 

List [Constraint] |Nil; 

Either the constraints upon the zero or more 
arguments of the operation that the responder defines, if 
20 they do not vary in number, or a nil, otherwise, in which 
case each is passed by reference and can be any object but 
a mark. The list's first item constrains the argument on 
top of the stack. 

result : 
25 Constraint | Nil; 

Either the constraint upon the result of the 
operation that the responder defines, if the operation has 
a result, or a nil, otherwise. 

Adaptations 
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i3Equal 

Two operation definitions are equal according to 
their attributes native to feature and operation 
definitions . 



10 5 4.54 Ordered 

Ordered 



Class 

Ordered: 

abstract interface () = (...)• 

10 Public Instance Operatin g 
isAfter: 

abstract op (object: protected Ordered) Boolean; 

Returns an indication of whether the responder is 
after the object (argument "object"). 
15 A method shall escalate this operation if either the 

responder or the object is not a member of the class to 
which the method is native. 

isBefore ; 

abstract op (object: protected Ordered) Boolean; 



20 



Returns an indication of whether the responder is 
before the object (argument "object"). 

A method shall escalate this operation if either the 
responder or the object is not a member of the class to 
which the method is native. 



45 25 max: 

op (object: Ordered) Ordered; 



so 
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Returns either the responder, if the responder is 
after the object (argument "object"), or the object, 
otherwise . 

min : 

op {object: Ordered) Ordered; 



Returns either the responder, if the responder is 
15 before the object (argument "object"), or the object, 

otherwise . 

4.55 Package 
20 io Object (Referenced) 

• Collection 

• • Set (Verified) 

• • • Constrained Set (Constrained) 

• • • • Package (Cited & Interchanged) 

15 Class 

EfMpkaqe : 

interface (ConstrainedSet [Class] , Cited, 
Interchanged) 

= (-..); 

20 Construction 

initialize : 

unprotected op (title: Identifier!; 
ma j orEdi t ion , minorEdi t ion : 
Integer; items: Class . . . ) 
25 throws ItemDuplicated, ProcessNotPeer ; 

Makes the responder' s items the classes (argument 
"items") and the responder' s "citation" attribute a 
citation whose "author" attribute is the current process' 
assigned telename and whose other attributes are the 
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like-named arguments (arguments "ma jorEdition" , 
"minorEdition" , and "title"). 

An exception is thrown if two classes are equal 
("ItemDuplicated") or the current process is not a class' 
5 peer ( "ProcessNotPeer" ) . 

Adaptations 

constraint 

The attribute is sealed. The attribute's "ofClass" , 
"classld", "islnstance", » isOptional " , and "passage" 
10 attributes are class -Class" , the identifier of class 
"Class" , "true", "false" , and "byCopy" , respectively. 

4 . 56 Pattern 
Object (Referenced) 
• Pattern (Ordered) 

15 Class 

Pattern: 

interface (Object, Ordered) » (...); 

Construction 

initialize • 

20 unprotected op (text: copied String!) 

throws Patternlnvalid; 

Makes the responder's text the string (argument 
"text") . 

An exception is thrown if the proposed text is 
25 invalid ("Patternlnvalid"). 

Public Insr ance Operations 
find: 

op (string: protected String!; position: Integer (Nil) 
List [Integer] |Nil 
30 throws Positionlnvalid; 
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Searches the string (argument "string" > for the first 
and longest possible substring that matches the responder. 
The search begins either at the prescribed position 
(argument "position"), if an integer is supplied, or at 
5 position one, otherwise. 

The operation returns either a nil, if the operation 
finds no match, or a list of two integers, otherwise. In 
the latter case, the first integer is the position in the 
string of the first character in the match. The second 
10 integer is one greater than the position in the string of 
the last character in the match. 

An exception is thrown if the proposed position is 
invalid as such, more specifically, less than or equal to 
zero ("Positionlnvalid" ) . 
15 Note: The two integers in the list are suitable as the 

arguments of operation "substring" . 

substitute : 

op ( repetitions: Integer; 

string: unprotected String!; 
20 replacement: protected String!) 

Integers- 
Searches the first string (argument "string"), 
beginning at position one, for the longest possible 
substrings that match the responder, and modifies the 
25 string by replacing each match with a copy of the second 
string (argument "replacement") . 

The operation finds either all matches, if the 
integer (argument "repetitions") is zero, or at most that 
many, otherwise. Successive matches are non- over lapping . 
30 If one match is of zero length, the search for the next 
begins at the following position. The operation returns 
the number of matches actually found. 

The replacement string can be tailored for each 
individual replacement. Wherever an ampersand ("&") 
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appears in the replacement string without being 
immediately preceded by a reverse slash (»\»), a copy of 
the substring to be replaced is itself substituted for the 
ampersand, and the modified replacement string then is 
5 substituted for the substring. 

Adaptations 
isEoual 

Two patterns are equal according to their texts. 

ConVfirflinng 

10 String 

A string that is valid as the text of a pattern 
produces that pattern. 

4.57 Permit 
Obj ect (Referenced) 
15 • Permit (Ordered) 

CTass 

Permit : 

interface (Object, Ordered) - (...); 

2 ° initially 

unprotected op (age, charges, extent: Integer ( Nil ) ; 

Makes the responder's attributes the like-named 
arguments (arguments "age", "charges", and "extent") 
Makes every other native attribute of the responder either 
25 "true", if the attribute is a boolean, or a nil, 
otherwise . 

Public Tnqh^ng AttriKnhoe 
aqre : 

Integer | Nil; 
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Either the maximum permitted age, measured in 
seconds, of the responder's subject, if a maximum is 

5 

imposed, or a nil, otherwise. 

authenticity; 
10 5 Integer | Nil; 

Either the maximum permitted authenticity of the 
responder's subject, if a maximum is imposed, or a nil, 
otherwise. 

charges : 
10 Integer | Nil; 

Either the maximum permitted charges, measured in 
teleclicks, of the responder's subject, if a maximum is 
imposed, or a nil, otherwise. 

extent : 
15 Integer | Nil; 

Either the maximum permitted size measured in octets 
of the responder's subject, if a maximum is imposed, or a 
nil, otherwise. 

priority: 
20 Integer | Nil; 
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Either the maximum permitted priority of the 
responder's subject, if a maximum is imposed, or a nil, 
45 otherwise . 



50 



canCharcre * 
25 Boolean; 
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Whether the responder's subject is permitted to 
request operation "charge". 

canCreate : 
Boolean; 

5 Whether the responder's subject is permitted to 

request operation "new" of a subclass of class "Process". 

canDenv : 
Boolean ; 

Whether the responder's subject is permitted to set 
10 the "nativePermit" attribute of a peer process so as to 
decrease the peer process' capabilities. 

Whether, coincidentally, the responder's subject, if 
otherwise entitled to do so, is permitted to so set a 
process' "regionalPermit ■ or "localPermit" attribute. 

15 canGo : 

Boolean; 

Whether the responder's subject is permitted to 
request operation "go" . 

canGrant r 
20 Boolean; 

Whether the responder's subject is permitted to set 
the "nativePermit" attribute of a peer process so as to 
increase the peer process' capabilities. 

Whether, coincidental^ , the responder's subject, if 
25 otherwise entitled to do so, is permitted to so set a 
process' "regionalPermit" or "localPermit" attribute. 

canRestarf ■ 
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Boolean; 

Whether the responder's subject is permitted to be 
restarted. 

cfriaSend: 
5 Boolean; 

Whether the responder's subject is permitted to 
request operation "send" . 

Public Instance Qn^^innc 
intersection ? 
10 op (permit: Permit) Permit; 

Returns the intersection of the argument (argument 
"permit") and the responder. 

Adaptations 
isAf ter 

15 one permit is after another iff they are not equal, 

no native attribute of the first is before that of the 
second, and at least one native attribute of the first is 
after that of the second. 



20 



25 



is Be fore 

One permit is before another iff they are not equal, 
no native attribute of the first is after that of the 
second, and at least one native attribute of the first is 
before that of the second. 

isEcrual 

Two permits are equal according to their native 
attributes . 

4 .58 Petition 
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Ob j ect (Referenced) 
• Petition 

Class 

Petition : 
5 interface = (...); 

Cons t rue fc ion 

initialize : 

unprotected op (agentName: Telename [Nil ; 
agent CI ass : Citation j Nil ; 
1 0 maximumWait : Integer | Nil ) ; 

Makes the responder's native attributes the 
like-named arguments (arguments "agentclass" , "agentName", 
and "maximumWait") . 

Public Insta nce AttHhnfAg 
15 agentclass : 

Citation | Nil; 

Either a citation to the class, a subclass of class 
"Agent" , of which the petitionee of the meeting the 
responder defines is a member, if such a constraint is 
2 0 imposed, or a nil, otherwise. 

agentName r 
Telename | Nil; 

Either a telename of the petitionee of the meeting 
the responder defines, if such a constraint is imposed, or 
25 a nil , otherwise . 

maximumWai,^ 
Integer | Nil; 
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5 Either the maximum permitted difference in seconds 

between the time at which the meeting the responder 
defines shall be arranged and the time at which the 
meeting is requested, if such a constraint is imposed, or 

10 5 a nil, otherwise. The integer, if supplied, is 

non- negative . 

Adaptations 
15 isEoual 

Two petitions are equal according to their native 
10 attributes. 

20 4.59 Petitioned 

Petitioned 

Class 

25 

Petitioned: 
15 abstract interface () = (...); 

30 System Instanc e Operations 

meeting: 

unprotected op (contact: Contact; 
petition: protected Petition) 
20 throws MeetingDenied; 
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Successfully performed before the subject of the 
contact (argument "contact") meets the responder using the 
petition (argument "petition"). The contact's subject 
attribute is a nil while the operation is being performed, 
25 and is made the "subject" iff the operation succeeds. 

An exception is thrown if the meeting is denied 
("MeetingDenied"). The method for this operation native 
to the class throws an exception. 

so parting: 

30 unprotected op (contact: Contact); 
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Requested after the subject of the contact (argument 
"contact") has met with the responder. Before the 
operation is requested, the Engine makes the contact's 
"subject" attribute a nil. The method native to class 
5 "Petitioned" has no effect. 

4.60 Place 

Ob j e c t ( Re f e r enced ) 

• Process (Named) 

• • Place (Unmoved) 

10 Class 

Place ; 

abstract interface (Process, Unmoved) = (-..); 



Construct ion 
25 initialize 

15 Makes the responder' s "address" attribute a newly 

assigned telename, which is a peer of the current 
process', and clears the responder' s "publicClasses" 
attribute . 

Public Instance Attributes 
20 address; 

sealed readonly protected Teleaddress; 

40 The responder 's assigned teleaddress. 

publicClasses : 

sealed readonly Set [Cited] ; 



25 The set of classes, packages, or both that the 

responder hereby makes accessible to its occupants. The 
attribute is either an unprotected reference, if the 
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requester is the place, or a protected reference, 
otherwise . 

Public Instance Operations 
terminate : 
5 sealed unprotected op 

(occupant: protected Telenarae) Boolean 
throws ProcessNotCurrent , ProcessNotPeer , 
Statelmproper ; 

Terminates any occupant of the responder having the 
10 assigned telename (argument "occupant") and returns an 
indication of whether there was such a process* The 
process is terminated by forcibly exhausting the process' 
native permit . 

An exception is thrown if the responder is not the 
15 current place ("ProcessNotCurrent"), the current process 
is not the occupant's peer ( "ProcessNotPeer" ) , or the 
requester's state precludes operation "terminate" 
("Statelmproper") . 

System Instance Operations 
20 entering : 

unprotected op (contact: Contact; 
permit: protected Permit; 
ticket: protected Ticket j Nil) 
throws OccupancyDenied ; 

25 Successfully performed before the subject of the 

contact (argument "contact") occupies the responder. The 
contact's "subject" attribute is a nil when the operation 
is requested, but is made the subject iff the operation 
succeeds . 

3 0 The subject is either an agent arriving with the 

ticket (argument "ticket"), if one is supplied, or a 
process being created in the responder, if a nil is 
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supplied. The permit (argument "permit") is the subject's 
proposed initial local permit. 

After this operation succeeds , iff the responder is a 
contacted object , the Engine includes the contact in the 
5 responder' s "contacted" attribute. 

An exception is thrown if the contact's subject is 
denied occupancy ( "OccupancyDenied" ) . The method for this 
operation native to the class throws an exception. 
Note : If a ticket is supplied, the permit equals and, 

10 therefore, duplicates the ticket's 

"dest inationPermit " attribute . 

exiting: 

unprotected op (contact: Contact; 
permit: protected Permit; 
15 ticket: protected Ticket (Nil) ; 

Requested once the subject of the contact (argument 
"contact") no longer occupies the responder. The 
contact's "subject" attribute is a nil when the operation 
is requested. The method for this operation native to the 
20 class has no effect. 

The subject is either an agent leaving the responder 
with the ticket (argument "ticket") , if one is supplied, 
or a process being destroyed within the responder, if a 
nil is supplied. The permit (argument "permit") is the 

2 5 subject's current local permit. 

After this operation is performed, iff the responder 
is a contacted object, the Engine excludes the contact 
from the responder' s "contacted" attribute. 

4.61 Primitive 

3 0 Object (Referenced) 

• Primitive (Executed & Unchanged) 

Class 
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Primitive : 

abstract interface {Object, Executed, Unchanged) 
(...); 

This class is sealed. 



5 Cons t rue t ion 

initialize : 
unprotected op {) 
is throws FeatureUnavailable; 

Throws an exception ("FeatureUnavailable") . 

10 4.62 Primitive Exception 
Object (Referenced) 

• Except ion ( Unchanged ) 

• • Programming Exception 

• • • Primitive Exception 

15 Class 

Primitive Exceotion : 

abstract interface (ProgrammingException) = () ; 

Subclasses 

DivisionBvZero : 
2 0 interface (PrimitiveException) = () ; 

40 A divisor is zero . 

4 . 63 Procedure 
Object (Referenced) 

• Primitive (Executed & Unchanged) 
25 • • Procedure 

so Class 

Procedure : 
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sealed interface (Primitive) = (...); 

Adaptations 
isEaual 

Two procedures are equal iff they are equal in length 
5 and their like-positioned items are equal. 

Convers ions 
List 

A list whose items are executed objects produces a 
procedure of the same length, each of whose items is a 
10 copy of that in the same position. 

OctetString 

An octet string that is a binary telescript produces 
a procedure whose items are the objects the binary 
telescript encodes . 

15 String 

A string that is a character telescript produces a 
procedure whose items are the objects the character 
telescript encodes . 

4 . 64 Process 
20 Object (Referenced) 
• Process (Named) 

Class 

Process ; 

abstract interface (Object, Named, Uncopied) » (...); 
25 This class is sealed. 

Construrr-inn 

initialize : 

op ( nativePermit : copied Permit; 
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privateClasses: Set [Cited] |Nil) 
throws Permitviolated; 

Makes the responder's "name" attribute a newly 
assigned telename, a peer of the current process'; the 
5 responder's attribute the like-named argument (argument 
"native Permit " ) ; the responder's "privateClasses" 
attribute either the like -named argument (argument 
"privateClasses") , if the argument is not a nil, or the 
like-identified attribute of the current process, 
10 otherwise; and the responder's contacts attribute a 
cleared set. 

An exception is thrown if the current process' 
effective permit forbids operation "new", that permit is 
otherwise inadequate, or operation "entering" fails 
15 ( "Permitviolated" ) . 
25 Note : The method for this operation native to a 

subclass of class "Process" sees the creating 
process, not the created one, as the current 
process . 

30 

20 Public Instance Attributes 
brand ; 

35 sealed readonly protected Object 

throws ProcessNotPeer; 

The responder's brand. 
40 25 An exception is thrown if the current process is not 

the responder's peer ("ProcessNotPeer") . 

localPermit : 
45 sealed copied Permit 

throws FeatureUnavailable, Permitviolated; 



3 0 The responder's local permit . 
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An exception is thrown if either the requester is 
neither the responder nor the place the responder occupies 
( "FeatureUnavailable") or an attempt is made to set the 
attribute in a way which is inconsistent with the Process 
5 Model ( "PermitViolated") . 

native Permit : 
sealed copied Permit 

throws FeatureUnavailable, PermitViolated; 

The responder 's native permit. 
10 An exception is thrown if either the requester is 

neither the responder nor a peer thereof 
("FeatureUnavailable") or an attempt is made to set the 
attribute in a way which is inconsistent with the Process 
Model ("PermitViolated") . 

15 PftKmfr ; 

sealed readonly copied Permit ; 

The responder' s effective permit. 

reaiona lPermit r 
sealed copied Permit 
20 throws FeatureUnavailable, PermitViolated; 

The responder' s regional permit. 

An exception is thrown if either the requester is 
neither the responder nor an engine place 
("FeatureUnavailable") or an attempt is made to set the 
25 attribute in a way inconsistent with the Process Model 
("PermitViolated") . 

privateClagsea = 

sealed readonly Set [Cited] 

throws ProcessNotPeer; 
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The set of classes, packages, or both the responder 
holds . 

An exception is thrown if the current process is not 
the responder' s peer ( "ProcessNotPeer" ) . 

5 Public Instance Operations 
charge : 

sealed op (charges: Integer) 

throws Permit Inadequate, PermitViolated; 

Increases the responder' s actual charges by the 
10 integer amount (argument "charges") . 

An exception is thrown if the responder' s effective 
permit would be exhausted ( "Permit Inadequate " ) or the 
current permit forbids operation "charge" 
("PermitViolated") . 

15 restrict : 

sealed op (procedure: Procedure; permit: protected 
Permit) 

throws Exception, PermitViolated, ProcessNotCurrent; 

Performs the procedure (argument "procedure") under 
20 the temporary permit (argument "permit") and the resulting 
effective permit of the current process, to which the 
procedure ' a charges accrue . 

An exception is thrown if the procedure does so 
("Exception"), the procedure's performance violates the 
25 effective permit designated above (" PermitViolated" ) , or 
the requester is not the current process 
("ProcessNotCurrent") . 

sponsor : 

sealed op (procedure: Procedure; permit: protected 
3 0 Permit) 

throws Exception, PermitViolated, ProcessNotCurrent; 
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Performs the procedure (argument "procedure") under 
the temporary permit ("permit") and the resulting 
effective permit of the responder's owner, to which the 
procedure's charges accrue. The procedure gets access to 
5 the requester's frame and properties, not the responder's. 
An exception is thrown if the procedure does so 
("Exception"), the procedure's performance violates the 
effective permit designated above ( "PermitViolated" ) , or 
the requester is 
10 not the current process ( "ProcessNotCurrent " ) . 

Private In stance Attributes* 

sealed readonly Integer; 

The responder's actual age in seconds. 

15 charges : 

sealed readonly Integer; 

The responder's actual charges in teleclicks. 
priority : 

sealed Integer) Nil; 



20 
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The responder's actual priority, i.e., the 
responder's chosen priority. 

Private Insta nce Operations 
wait i 

unprotected op (seconds: Integer) ; 

Blocks the responder until the requested number of 
seconds (argument "seconds") have elapsed. If the integer 
is negative, the operation has no effect. 
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System Instance Operations 
live : 

abstract unprotected op (cause: Exception (Nil) 
throws Exception; 

5 Requested with a nil (argument "cause") to start the 

responder after its creation. If the "canRestart " 
attribute of the permit the responder holds is "true", the 
operation is requested with an exception (argument 
"cause") to restart the responder if the responder fails 

0 due to that exception. 

An exception is thrown if the responder fails to 
catch the exception ("Exception"). 

restricted: 

op (permit: Identifier; isRelocated: Boolean) 
5 Permi tReduced | Ni 1 ; 

Requested if the responder' s attribute 
"nativePermit" , " regional Permit " , or "localPermit " , once 
set, is set again so as to reduce the responder' s 
capabilities- The identifier (argument "permit") is that 

0 of whichever of these three attributes was set . The 
Engine throws the operation's result in the responder' s 
thread if the result is not a nil. The method native to 
this class simply returns a nil. 

The boolean (argument "isRelocated") indicates 

5 whether the event leading the Engine to request the 

operation also led the Engine to transport the responder 
to a place, e.g., a purgatory, other than either the one 
the responder occupied or, if the operation is requested 
during the performance of operation "go" or "send", the 

0 responder' s destination. In the latter case, operation 
"go" or "send" throws the present operation's result if 
not a nil . 
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Note; The responder's ability to perform this 

operation, when the responder's newly set permit 
is severely restrictive, is limited by the rules 
of process termination. 

5 Adaptations 
copy 

A member of "Copy Unavailable" is thrown. 

4 -65 Process Excep tion 
Obj ect (Referenced) 
10 • Exception (Unchanged) 

• • Programming Exception 

• • • Process Excep tion 

Class 

ProcessException, . 
15 abstract interface (ProgrammingException) = () ; 

Subclasses 

Permit Inade>g nai-e ■ 

interface (ProcessException) = () ; 

One process tries to charge another so as to exhaust 
20 the latter' s effective permit. 

Condi tion-Unavailable • 

interface (ProcessException) » () ; 

A process manipulates the condition of a resource 
without exclusive use of the resource. 
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ConditionUndef ined ; 

interface (ProcessException) = (); 

An identifier purporting to denote a resource's 
condition does not. 

5 PermitExhausted ; 

interface (ProcessException) = () ; 

A process exhausts the permit that the process holds 
PermitViolated : 

interface (ProcessException) = () ; 
10 A process violates the permit that the process holds 

ProcessNotCurrent : 

interface (ProcessException) = {); 

A process requests a feature of other than the 
current member of a class, 

15 ProcessNotPeer - 

interface (ProcessException) « (); 

An object manipulates a process that is not the 
object's peer. 

ResourceUnavailable 
20 interface (ProcessException) = () ; 

A resource's use cannot be obtained in the number of 
seconds requested. 
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Statelmproper ; 

interface (ProcessException) = (); 



A process requests a feature while in a state that 
precludes the request. 



5 4.66 Programming Excenti rm 
Object (Referenced) 
15 • Exception (Unchanged) 

• • Programming Exception 

Class 

20 10 ProaramminaExcep t ion « 

abstract interface (Exception) = (),- 



4.67 Qualified Identifier- 
Object (Referenced) 

• Primitive (Executed & Unchanged) 
15 • • Identifier (Ordered) 

• • • Qualified Identifier- 
Class 

Oualif iedldent if i Pr ■ 

sealed interface (Identifier) () ; 

20 4.68 Random Stream 
Ob j ect (Referenced) 

• Stream 

• • Random Stream 



Class 

45 25 RandpmStream: 

interface (Stream [Integer] ) ^ (...); 
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Construction 

initialize: 

unprotected op (seed: Integer) 
throws Seedlnvalid; 

5 Makes the responder's seed the integer (argument 

"seed"), makes the responder's "current" attribute a nil, 
and leaves the responder's "next" attribute undefined. 

An exception is thrown if the proposed seed is 
invalid as such ( "Seedlnvalid" ) . 

10 Adaptations 
current 

This attribute is an integer. 
next 

This attribute is an integer, and not a nil. 

15 4.69 Real 

Object (Referenced) 

• Primitive (Executed & Unchanged) 

• • Number (Ordered) 

• • • Real 

20 Class 

Real : 

sealed interface (Number) = () ; 

Adap tat ions 
abs 

25 The result is a real . 

add 

The result is a real. 
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divide 

The result is a real. 
multiply 

The result is a real. 

5 negate 

The result is a real . 

subtract 

The result is a real . 

Conversion a 
10 Bit 

A bit produces the result of first converting the bit 
to an integer, and then converting the integer to a real. 

BitString 

A bit string produces the result of first converting 
15 the bit string to an integer, and then converting the 
integer to a real. 

Boolean 

A boolean produces the result of first converting the 
boolean to an integer, and then converting the integer to 
20 a real. 

40 Character 

A character produces the result of first converting 
the character to an integer, and then converting the 
integer to a real . 
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25 Integer 

An integer produces the real that is equal to the 
integer arithmetically. 
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Octet 

An octet produces the result of first converting the 
octet to an integer, and then converting the integer to a 
real . 

OctetStrina 

An octet string produces the result of first 
converting the octet string to an integer, and then 
converting the integer to a real . 



String 

10 A string that obeys the syntactic rules for the Real 

20 token in Character Telescript produces the corresponding 

real . 



4.70 Referenced 
Referenced 

15 Class 

Referenced: 

abstract interface () = (...); 

This class is sealed. 

Public Instance Attributes 
2 0 isProtected : 

sealed readonly Boolean ; 



Whether the reference to the responder is protected. 



45 Public Instance Operations 

discard : 
25 sealed op () ; 



Destroys the responder iff no references to the 
responder remain. 
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isSame : 

sealed op (reference: protected Referenced) Boolean 

Returns an indication of whether the referenced 
object (argument "reference") is the responder. 

5 protect : 

sealed op () protected Referenced; 

Returns a protected reference to the responder. 
ref : 

sealed unprotected op () ; 

0 Pushes onto the stack two references to the 

responder, both protected iff the reference used to 
request the operation is itself protected. 



4 . 71 Resource 
Ob j ect (Referenced) 
15 • Resource 

Class 

Resource : 

interface = (...); 



Construction 
20 initialise ; 

unprotected op {condition: Identifier! [Nil ; 

conditions: copied Set [Identifier I ] j Nil) 
throws Condi tionUndef ined; 

Makes the responder' s native attributes the 
25 like-named arguments (arguments "condition" and 

"conditions") . if either argument is a nil, both must be 
nils, and in that eventuality, the "conditions" attribute 
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comprises one identifier which equals the "condition" 
attribute. The identifier in question is undefined. 

An exception is thrown if the individual condition, 
i.e. the "condition" attribute, is not in the set, i.e. 
5 not in the "conditions" attribute ( "Condi tionUnde fined" ) . 

Public Instance Attributes 
condition : 
Identifier! 

throws Condi tionUnavail able; 

0 The identifier for the responder's condition. 

An exception is thrown if the current process 
attempts to set the attribute and lacks exclusive use of 
the responder ( "Condi tionUnavail able" ) . 

conditions * 
5 readonly protected Set [Identifier!]; 

The identifiers for the responder's possible 
conditions . 



Public Inst ance Operations 
use : 

20 sealed unprotected op (procedure: Procedure; 

exclusive: Boolean I Nil; 
maximumWait : Integer | Nil ; 

conditions: copied Set [Identifier!] (Nil) 

Boolean 

25 throws Condi tionUndef ined, Exception, 

ResourceUnavailable ,- 

Obtains use of the responder, performs the procedure 
(argument "procedure"), and then relinquishes the 
responder, even if the procedure fails. The procedure 
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gets access to the requester's frame and properties, not 
the responder's. 

The use is exclusive iff the boolean (argument 
"exclusive") is both present and "true". Iff a set of 
5 identifiers (argument "conditions" ) , not a nil, is 

supplied, the use is granted only when the responder is in 
one of the conditions the identifiers denote. 

If an integer (argument "maximumWait " ) is supplied, 
the operation waits for use of the responder no more than 
10 that many seconds. If a nil is supplied instead, the 
operation waits as long as required, possibly forever. 
The operation's result indicates whether, in the former 
case, the responder remained unavailable after the 
indicated number of seconds . 
15 An exception is thrown if the set of conditions is 

cleared or does not equal a subset of the responder's 
-conditions" attribute ( "Condi tionUnde fined" ) , the 
procedure throws an exception ("Exception"), or the 
responder's use cannot be obtained in the number of 
20 seconds requested ( "Res our ceUna vail able" ) . 

4.72 Selector 
Object (Referenced) 

• Primitive (Executed & Unchanged) 

• • Selector 

25 Class 

Selector: 

sealed interface (Primitive) « () ; 

Adaptations 
ifiEcual 

30 Two selectors are equal iff their values are the 

same . 
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4.73 Set 

Ob j ect ( Re f erenced) 

• Collection 

• • Set (Verified) 

5 Class 

Set : 

interface [itemClass: Class] 

(Collection [itemClass] , Verified) = (...); 



Parameterized by the class (argument "itemClass") of 
10 which each item of each member of the subject class is 
20 itself a member. 

Construct- inn 

initialize ; 

25 unprotected op (items: itemClass ...) 

15 throws ItemDuplicated, Itemlnvalid; 

^ Makes the responded s items the objects (argument 

"items") . 

An exception is thrown if two proposed items are 
equal C "ItemDuplicated" ) or a proposed item is invalid as 
35 20 such ("Itemlnvalid") . 

Public Insta nce Operations 
difference ? 

40 

unprotected op (set: protected Set [itemClass]); 

Excludes from the responder and discards every item 
^ 25 that equals an item of the set (argument "set"). 
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intersection ; 

unprotected op (set: protected Set [itemClass] ) ; 

Excludes from the responder and discards every item 
that does not equal an item of the set (argument "set") . 

5 union: 

unprotected op (set: protected Set [itemClass]); 

Includes in the responder a reference to each item of 
the set (argument "set") that does not equal an existing 
item of the responder. 

10 Adaptations 
include 

An object is included in a set as a new item by first 
excluding and discarding any existing item equal to the 
object . 



15 verify 

A set is consistent iff no two of the set's items are 
equal . 



4.74 Stack 
Ob j ec t (Referenced) 
20 • Collection 

• • List (Ordered) 

• • • Stack 
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Class 

Stack : 

interface [itemClass : Class] (List [itemClass]) = 
{...); 

5 Parameterized by the class (argument "itemClass") of 

which each item of each member of the subject class is 
itself a member. 

Public Instance Operations 

POP : 

10 unprotected op () itemClass 

throws StackDepleted; 

Removes from the responder and returns its top item. 
An exception is thrown if the responder is cleared 
("StackDepleted") . 

15 push : 

unprotected op (item: itemClass) ; 

Adds the object (argument "item") to the responder as 
a new item at its top. 

pushl terns : 

20 unprotected op (items: protected List [itemClass]); 

Pushes onto the responder references to the items of 

the list (argument "items"). A reference to the item at 

position one of the list is placed on top of the 
responder. 
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roll : 

unprotected op (shifts, items: Integer) 
throws Argumentlnvalid, StackDepleted; 

Shifts the topmost items of the responder. 
The number of items, "I", participating in the shift 
is given by one integer (argument "items") which shall be 
non-negative. The number of positions, »p», that each 
participating item is to be shifted is given by another 
integer (argument "shifts") which may be either positive 
10 or negative, "P" being its absolute value. The 
participating items are shifted toward either the 
responder' s top, if this second integer is positive, or 
the responder' s bottom, otherwise. 

To shift the participating items one position toward 
15 the responder' s top is to change the position of the 

topmost item to "I" and to decrease by one the position of 
each of the other participating items. 

To shift the participating items one position toward 
the responder' s bottom is to make topmost the item whose 
20 position is "I" and to increase by one the position of 
each of the other participating items. 

An exception is thrown if the integer giving «i» is 
negative ("Argumentlnvalid") or the responder 's length is 
less than "I" ("StackDepleted") . 

25 swap : 

unprotected op () 
throws StackDepleted; 

Transposes the items at positions one and two of the 
responder . 

30 An exception is thrown if the responder' s length is 

less than two ("StackDepleted"). 
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4.75 Stream 

Object (Referenced) 

• Stream 

Class 
5 Stream: 

abstract interface [itemClass : Class] « (...); 

Parameterized by the class (argument "itemClass") of 
which each item of each member of the subject class is 
itself a member. 

10 Public Instance Attributes 
current : 

abstract readonly itemClass | Nil ; 

Either the item the responder produced last, if 
attribute "next" of the responder has been queried but has 
15 not returned a nil having produced all of the responder' s 
items, or a nil, otherwise. 

isDone: 

abstract Boolean; 

Whether the responder has produced all of its items. 

20 next : 

abstract readonly itemClass j Nil 
throws ReferenceProtected; 

Either the next item of the responder, if the 
responder has not produced all of its items already, or a 
25 nil, otherwise. The responder produces another item each 
time this operation is requested. 

An exception is thrown if the responder is protected 
{ "ReferenceProtected" ) . 
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4 .76 String 

Obj ect (Referenced) 

• Collection 

• • List (Ordered) 

5 # • • Constrained List (Constrained) 

• • • • String (Cased & Executed) 

Class 

String: 

sealed interface 

10 (ConstrainedList [Character], Cased, Executed) 

(...); 

Construct ion 

initialize : 

unprotected op (segments: Object ... 
15 /* Character (protected String! */) ; 

Makes the responder a concatenation of the segments 
(argument "segments") whose positions in the responder 
increase from left to right. 

Public Tn.g^nce Ope -rat ions? 
20 substring : 

op (initialPosition, beyondFinal Posit ion: Integer) 
copied String 
throws Positionlnvalid; 



25 



Returns a copy of the substring of the responder that 
comprises the characters at the positions in the range 
["initialPosition", "beyondFinalPosition" ) . 

An exception is thrown if an asserted position is 
invalid as such ("Positionlnvalid"). 
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Adaptations 

constraint 

The attribute is sealed. The "constraint" 
attribute ' s "of Class " , n classic!" , " islnstance " , 
5 "isOptional" , and "passage" attributes are class 

"Character", the identifier of class "Character", "true", 
"false", and "byCopy", respectively. 

isAf ter 

One string is after another as if enough characters 
10 were first appended to the shorter string to make the 

shorter string equal in length to the longer string, each 
appended character being that whose Unicode code is the 
integer zero. 

isBef ore 

15 One string is before another as if enough characters 

were first appended to the shorter string to make the 
shorter string equal in length to the longer string, each 
appended character being that whose Unicode code is the 
integer zero. 

20 Conversions 
Bit 

A bit that can be converted to a character that can 
be converted to a string produces that string. 

CalendarTime 

2 5 A calendar time produces a string describing the time 

represented by the calendar time. 

Character 

A character produces a string whose only item equals 
the character. 
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Identifier 

An identifier produces a string that equals the 
iden t i f ier ' s text . 

Integer 

5 An integer produces a string that obeys the syntactic 

rules for the "Integer" token in a character telescript. 

Pattern 

A pattern produces a string that equals the pattern's 

text , 
10 Real 

A real produces a string that obeys the syntactic 
rules for the "Real" token in a character telescript. 

Telenutnber 

A telenumber produces the concatenation of a plus 
15 sign ("+"), the telenumber' s country attribute, a space 
(■ n ), and the telenumber's "telephone" attribute. 

Time 

A time produces the result of first converting the 
time to a calendar time, and then converting the calendar 
20 time to a string. 

4 . 77 Teleaddress 
Object (Referenced) 
• Teleaddress 

Class 
2 5 Teleaddress : 

interface = (...); 
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initialize: 

unprotected op (provider: OctetString! (Nil ; 
location: String! jNil) ; 

Clears the responder's "routingAdvice" attribute and 
makes its other native attributes the like -named arguments 
(arguments "location" and "provider") . If the latter 
argument is a nil, however, the "provider" attribute is 
made that of the current place's assigned teleaddress. 



10 Public Instance Attributes 
20 location : 

String! |Nil; 



Either the string denoting the location of the places 
denoted by the responder, if the latter is assigned or 
15 such a constraint is imposed, or a nil, otherwise. 

provider : 
OctetString! ; 



The octet string denoting, as does a telename'i 
35 "authority" attribute, the provider of the region 

20 containing the places the responder denotes. 



routingAdvice : 

List [OctetString!] ; 

Octet strings denoting, as does the "provider" 
attribute, and in order of decreasing preference, the 
25 providers of transit regions. 



so 
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Adaptations 
isEqual 

Two teleaddresses are equal according to their native 
attributes. 

5 4 . 78 Tele name 

Object (Referenced) 
• Telename 

Class 

Telename ; 
10 interface = (...); 

Construction 

initialing, 

unprotected op (authority, identity: 
OctetString! |Nil) ; 

15 Makes the responder's native attributes the 

like -named arguments (arguments "authority" and 
"identity"). if the former argument is a nil, however, 
the "authority- attribute is made that of the current 
process' assigned telename. 

20 Public Instance Attrihiir^c 
authority? 
OctetString! ; 

The octet string denoting the authority of the named 
objects the responder denotes. 

25 identity * 

OctetString! jNil; 

Either the octet string denoting the identity of the 
named object denoted by the responder, if the latter is 
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assigned or such a constraint is imposed, or a nil, 
otherwise . 

Adaptations 
isEaual 

5 Two telenames are equal according to their native 

attributes . 

4-79 Telenumber 
Object (Referenced) 
• Telenumber 

10 Class 

Telenumber : 
interface = (.«.); 

Construction 

initialize : 

15 unprotected op ( count ryAndTelephone : String!; 

extension: String! |Nil) ; 



Makes the responder's "extension" attribute the 
like-named argument (argument "extension") and the 
35 responder's other native attributes those of a telenumber 

20 that can be converted to the "count ryAndTelephone" 
argument . 

40 Public Instance Attributes 

country : 
String! ; 



25 The code that CCITT assigns to the country or other 

geographical area in which the instrument the responder 
denotes is located [CCITT] . Each character of the string 
is a numeral ( n 0"-"S n ) m 
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extension : 
String! (Nil; 



Either the telephone extension that unambiguously 
identifies the instrument the responder denotes, if the 
5 responder's "country" and "telephone" attributes do not do 
that themselves, or a nil, otherwise. Each character of 
the string is a numeral ("0»-"9"), a hyphen {"-»), or a 
space (" " ) . 



telephone : 
10 String! ,- 

The number assigned to the instrument the responder 
denotes by the country or other geographical area the 
"country" attribute denotes. Each character of the string 
is a numeral ("0"-»9"), a hyphen (»-"), or a space (" ") . 

15 Adaptations 
isEqual 

Two telenumbers are equal according to their native 
attributes, which are equal as if all hyphens {»-») and 
spaces <» «) were first dropped from them. 

20 Conversions 
String 

A string that can be produced by converting some 
telenumber produces that telenumber, whose "extension" 
attribute is a nil. 



25 4.80 Ticket 

Object (Referenced) 

• Ticket Stub 

• • Ticket 
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Cia^s 

Ticket : 

interface (TicketStub) = (,..); 

Cons t rue t ion 
5 initializer 

unprotected op (destinationName : Telename |Nil ; 
destinationAddress ; Teleaddress | Nil ; 
15 destinationClass : Citation ( Nil ; 

maximumWait : Integer I Nil ; 
10 way: Way] Nil; 

travelNotes : Ob j ect | Nil ) ; 
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Makes the responder's "desiredWait ■ and 
"destinationPermit" attributes nils, the responder's other 
attributes the like-named arguments (arguments 
15 "destinationAddress", "destinationClass", 

"destinationName" , "maximumWait" , "travelNotes" , and 
"way", respectively) . 



Public Ins tance Attributes 
desiredWait ; 
20 Integer | Nil; 

Either the maximum desired difference in 
seconds- -non-negative- -between the time the trip the 
responder defines should be completed and the time the 
trip is requested, if such a constraint is imposed, or a 
25 nil, otherwise. 

de s t ina t ionAddresg ; 
Teleaddress | Nil ; 

Either a teleaddress of the destination of the trip 
the responder defines, if such a constraint is imposed, or 
30 a nil, otherwise. 
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destinationClass : 
Citation j Nil ; 

Either a citation to the subclass of class "Place" of 
which the destination of the trip the responder defines is 
5 a member, if such a constraint is imposed, or a nil, 
otherwise . 

destinationNamR - 
TelenatnejNil; 

Either a telename of the destination of the trip the 
10 responder defines, if such a constraint is imposed, or a 
nil, otherwise. 



destinationPp.rmi i- 
25 Permit | Nil; 



Either the local permit an agent using the responder 
15 shall have at the agent's destination, if that permit 
differs from the agent's current temporary permit or, if 
the agent has none, the agent's native permit; or a nil, 
otherwise . 



maximumWait : 
20 Integer | Nil; 

^ Either the maximum permitted difference in seconds 

between the time at which the trip the responder defines 
shall be completed and the time at which the trip is 
requested, if such a constraint is imposed, or a nil, 

45 25 otherwise. The integer, if supplied, shall be 
non -negative . 



so 
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Adaptations 
isEaual 

Two tickets are equal according to their attributes 
native to tickets and ticket stubs. 

5 4.81 Ticket Stub 
Object (Referenced) 
• Ticket Stub 

15 Class 

TicketStub - 
10 interface = (...); 

20 

Construction 

initialize ; 

unprotected op (way: Way | Nil; travelNotes: 
25 Object | Nil) ; 

15 Makes the responder's native attributes the 

^ like-named arguments (arguments "travelNotes" and "way"). 

Public Instan ce Attrihnh^c 
travelNotes : 
35 Object|Nil; 

20 An object for the exclusive use of the agent holding 

the responder . 



40 



45 



so 



way: 

Way | Nil; 



In a ticket, either the way to be taken to the trip's 
25 destination, if such a constraint is imposed, or a nil. 
In a ticket stub, a way back to the trip's origin. 
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Adaptations 
is Equal 

Two ticket stubs are equal according to their native 
attributes . 



5 4.82 Time 

Object (Referenced) 

• Time (Ordered & Unchanged) 



Class 

Time: 

interface (Object, Ordered, Unchanged) = (...); 

Construction 

initialize 

Makes the responder the current time, namely, that at 
the current place. 



15 Public Instanc e Operations 
adjust : 

op (seconds: Integer) Time; 



Returns a time that is the requested number of 
seconds (argument "seconds-) after the responder and that 
20 identifies the same permanent and seasonal offsets. 

Note: if the integer is negative, the time returned 

precedes the responder. 

interval ; 

op (subtrahend: Time) Integer; 

25 Returns the arithmetic difference in seconds between 

the responder, which is the minuend, and the time 
(argument "subtrahend"), which is the subtrahend. 
Note: The result measures the distance between two 

absolute points in time. 
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Adaptations 
5 isA^ter 

One time is after another iff the absolute point in 
time that the first identifies follows the absolute point 
5 in time that the second identifies. 

10 

isBefore 

One time is before another iff the absolute point in 
15 time that the first identifies precedes the absolute point 

in time that the second identifies - 

10 isEcnial 

20 Two times are equal iff neither is before the other. 



Con ve r s i ong 

CalendarTime 

A calendar time produces a time denoting the same 
15 point in time and the same permanent and seasonal offsets 



^ 4.83 Trip Exception 

Object (Referenced) 

• Exception (Unchanged) 

• • "Trip Exception" 

35 

20 Class 

TripException : 

abstract interface (Exception) = (...); 

40 

Cons t met ion 

initializer 

^ 2 5 unprotected op (ticket Stub: TicketStub) ; 



Makes the responder's native attribute the like-named 
argument (argument "ticketstub" ) . 

so 

Subclasses 
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DestinationUnavailable ; 
interface (TripException) = () ; 

A trip's destination is unreachable because the 
Network is partitioned. Thus the destination may be 
5 reachable in the future. 



DestinationUnknown ? 
15 interface (TripException) = () ; 

A trip's destination cannot be identified and thus is 
unreachable . 

20 

10 OccupancvDenied : 

interface (TripException) = () ; 

25 

A trip's destination denies the agent occupancy and 
therefore arrival . 

30 TicketE xpired: 

15 interface (TripException) = () ; 



A trip's destination cannot be reached in the number 
of seconds requested by the "maximumWait «» attribute of the 
ticket for the trip. 



WavUnavai labia i 
20 interface (TripException) = () ; 



25 



A trip's origin lacks the way required for the trip. 

Public Instance Attrihnfpc 
ticketSEnh; 
sealed TicketStub; 

The ticket stub resulting from the unsuccessful trip. 
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Adaptations 

Two trip exceptions are equal according to their 
native attributes. 

5 4.84 Unchanged 
Unchanged 

Class 

Unchanged : 

abstract interface C ) = ( ) ; 

10 Adaptations 
copy 

A copy of an unchanged object is the original. 

4.85 Unexpected Exception 
Object (Referenced) 
15 • Exception (Unchanged) 

• Programming Exception 

• • Kernel Exception 

• • • Execution Exception 

• • • • "Unexpected Exception" 

20 Class 

UnexpectedException r 

interface (ExecutionException) = (...); 

Construction 

initialize: 

25 unprotected op (exception: Exception) ; 

Makes the responder's native attribute the like-named 
argument (argument "exception") . 
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Public Instance Attributes 
exception; 
readonly Exception; 

The exception, which a feature did not declare but 
5 nevertheless threw, that is the cause of the responder. 

4 . 86 Unmoved 
Unmoved 

Class 

Unmoved : 

10 abstract interface () = () ; 

4.87 Verified 
Verified 

Class 

Verified: 

15 abstract interface () = (...); 

Public Instan ce Operations 
verify: 

abstract op {) Boolean; 

Returns an indication of whether the responder is 
20 consistent. 

4.88 Way 

Ob j ect (Referenced) 
• Way 

Class 
25 Way: 

interface = (...); 
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Construction 

initialize; 
unprotected op ( 



name : Te 1 ename J Ni 1 ; 
means : Means j Nil ; 

authenticator : Authenticator | Nil) ; 



Makes the responder's native attributes the 
like-named arguments (arguments "authenticator" , "means", 
15 and "name") . 

10 Public Instance Attributes 
authenticator = 
Authenticator | Nil ; 



Either the authenticator to be used to enter the 
25 region through which the way passes, if such a constraint 

15 is imposed, or a nil, otherwise. 



means : 
Means 'Nil; 



Either the means by which the region through which 
the way passes is to be accessed, if such a constraint is 
2 0 imposed, or a nil, otherwise. 

name: 

Te 1 ename | Nil; 

Either the telename of the region through which the 
way passes, if such a constraint is imposed, or a nil, 

45 

25 otherwise. 

Adaptations 
so isEqual 
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Two ways are equal according to their native 
attributes . 

5 TELES CR I PT SYNTAX 

A " telescript n is an encoding of a procedure. The 
5 abstract syntax of telescripts in general, and the 
concrete syntax of character and binary telescripts in 
particular, are defined in this section of this appendix. 
Not£: Character telescripts are used by people, binary 

telescripts by machines, e.g., when transporting 
10 objects between them. A binary telescript is 

almost always considerably fewer octets in 
length than the functionally equivalent 
character telescript. 

5 . 1 Telescript 

15 A telescript is a series of tokens comprising, first, 

a preface and, second, the procedure that the telescript 
encodes. The preface identifies the major and minor 
versions of the Instruction Set to which the telescript 
conforms . 

2 0 A telescript obeys the syntactic, and accompanying 

semantic, rules below. Given in BNF, the rules surround 
optional tokens by brackets ("[" and "]"): 
Telescript ::= Preface Procedure 

Body ::= [ExecutedObject Body] 
25 ExecutedObject :: = Bit | BitString | Boolean | 

Character | Identifier j Integer | 

Octet | OctetString | Mark | 
Modifier j Ni i j Procedure | Qldentifier ( 

Real | Selector j String 
= BitZero | BitOne 
= BooleanFalse j BooleanTrue 
= Modif ierDemarcate | 
Modif ierGetClass j 
Modi f ierGe t Property | 



30 Bit 
Boolean 
Modifier 
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Modif ierGet Variable , 
Modi fierMent ion | 
Modif ierSetAttribute | 
Modif ierSetProperty | 
5 Modif ierSetVariable | 

Modif ierUseStack 
Selector ::- SelectorBreak | 
SelectorClient \ 
Select orContinue | 
i0 SelectorEscalate | 

SelectorPlace j 
SelectorProcess | 
SelectorSelf | 
SelectorSucceed 



15 A telescript can include comments, the provision for 

which is considered among the syntactic rules. A 
"comment" is a string that does not affect the procedure 
the telescript encodes. One or more comments can appear 
before the script's first token, after its last, and 
20 between any two adjacent tokens. 

Note: A comment usually describes an aspect of a 

telescript to a human being. 
Note: The major and minor versions of the Instruction 

Set as defined in this appendix are identified 
25 fay zero ("0") and eight ( n 8 B ), respectively. 

5 . 2 Character Telescript 

A "character telescript" is a procedure encoded as a 
string. The abstract syntactic rules for telescripts in 
general are made concrete for character telescripts in 
30 particular in this section. 

Each token in a character telescript is one or more 
characters. The character telescript is obtained by 
concatenating the tokens, and thus the characters, and by 
inserting break characters between tokens. 
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A break character is a space ('• »), a horizontal tab, 
or a line feed. One or more such characters can appear 
before the first token, after the last, or between any two 
adjacent tokens. in the last case, at least one must 
5 appear if the two adjacent tokens comprise only numerals 
("0"- w 9") and letters, except when both tokens are either 
"BinDigit" or "hexDigitPair" . 

Terminals beginning with number sign ('•#«> and the 
keyword "telescript" are case - insensitive . While 
10 upper-case characters appear in this appendix, lower-case 
characters, or a mix of the two, can be used in 
programming. 

5-2.1 Preface and Cnmm^nt- 

Preface 

15 A preface obeys these rules: 

Preface : := telescript Version 
Version numerals : numerals 

The first "numerals" identifies the major version of 
the Instruction Set to which a character telescript 
20 conforms, the second "numerals" identifies the minor 
version. 



Comment 

A comment obeys this rule : 

Comment :: - /* comment 1 */ | // comment 2 
„ 25 Hote: The syntax rules fQr comments are thQse Qf 

C++ programming language. 

5 -2-2 Executed Qb-i^ rt-g 

45 Bit 

A bit obeys these rules, which individually encode 
3 0 the bit's values: 



so 



BitZero : := #b ' 0 
BitOne : : » #b ' 1 
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BitStrinq 

A bit string obeys these rules: 

BitString ::= #b " BinDigits n 
BinDigits ::= [BinDigit BinDigits] 

5 The i* "BinDigit" represents the bit at position 

of the bit string. 

Boolean 

A boolean obeys these rules, which individually 
encode the boolean' s values: 
0 BooleanFalse ; ; = #false 

BooleanTrue : := #true 

Character 

A character obeys this rule: 

Character : := # c / characters ' 

"characters" shall stand for one character. Each 
character stands for itself, with exceptions as defined 
for class "String". 

Identifier 

An identifier obeys this rule: 

Identifier :: = identifier | ] 

"identifier" is the identifier's text. The right 
square bracket ["] "] denotes operation "new". 

Integer 

An integer obeys this rule: 

Integer : : = [-] numerals 

Mark 

A mark obeys this rule: 

Mark : : = ftmark | [ 
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Note : 



Left square bracket [«["] is provided for 
possible use, by convention, with right square 
bracket ["] »] (see token "Identifier" above). 



Modifier 

5 A modifier obeys these rules, which individually 

encode the modifier's values. 
Modif ierDemarcate 



Modif ierGetClass : 
Modif ierGetProperty : 
10 Modif ierGetVariable : 

Modif ierMent ion : 
Modif ierSetAt tribute : 
Modif ierSetProperty : 
Modif ierSetVariable : 
15 Modif ierUseStack : 



% 
$ 



=$ 



Nil 

A nil obeys this rule; 
Nil #nil 



20 



25 



Octet 

An octet obeys this rule: 

Octet #o ' hexDigitPair ' 

The MSB of "hexDigitPair" represents Bit 7 of the 
octet, the LSB represents Bit 0. 

OctetString 

An octet string obeys these rules: 

OctetString : : = #o » HexDigitPairs « 
HexDigitPairs ::= [hexDigitPair HexDigitPairs] 

The first "hexDigitPair" represents the octet at 
position one of the octet string, the second that at 



316 



EP 0 634 719 A2 



position two, etc. The MSB of each "hexDigitPair" 
represents Bit 7 of that octet, the LSB represents Bit 0. 

Procedure 

A procedure obeys this rule: 
5 Procedure : : = { Body } 

Oualif iedldentif ier 

A qualified identifier obeys this rule: 
Qldentifier : : = identifier :: identifier 

The first "identifier" represents the text; the 
10 second represents the qualifier. 

Real 

A real obeys these rules: 

Real : : » Number [Exponent] 
Number : : = Integer . numerals | 
15 Integer . | 

numerals 
Exponent : : => E Integer 

The real's integral part is either the "Integer" in 
"Number" , if present, or zero, otherwise. The real's 
20 fractional part is either "numerals", if present, or zero, 
otherwise. The "Integer" in "Exponent", if present, is a 
power of ten. 

Selector 

A selector obeys these rules, which individually 
25 encode the selector's values: 



SelectorBreak 
SelectorClient 
SelectorContinue 
SelectorEscalate 
3 0 SelectorPlace 



- #break 
= #client 
= #continue 
= #escalate 
= there 
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SelectorProcess : := #process 

SelectorSelf : := #self j * 
SelectorSucceed : := #succeed 



String 

5 A string obeys this rule: 

String : := [#c] " characters " 

"characters" stands for zero or more characters. 
Each character stands for itself, except that a reverse 
slash ("\" ) and four hexadecimal digits («o ,, - r, 9" / »a b -"F") 
0 stand for the character whose Unicode code is the unsigned 
integer the digits represent, a character pair in Table 
A. 6 for the indicated character. 



TABLE A. 6 



Character Sequence 


Sinale Character 


\b 


Backspace 


\f 


Form feed 


\n 


Line feed (newline) 


\r 


Carriage return 


\t 


Horizontal tab 


\v 


Vertical tab 


\- 


Quotation mark {"«») 


\\ 


Reverse slash ("\") 



25 

a 



5.2.3 Other Non-terminals 

characters 

Zero or more characters, each a printing character or 
space (» «). a quotation mark (") shall be preceded by 
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a reverse slash . A reverse slash either shall be a 

part of a character sequence in the table found under 
token "String" above, or shall precede four hexadecimal 
digits . 

5 comment 1 

Zero or more characters, not including an asterisk 
immediately followed by a slash ("*/") . 

Note: "commentl" can encompass "/*» or "//" without 

special meaning, and thus can encompass a 
10 "comment2 n . 

comment 2 

Zero or more characters, not including a line feed. 
Note: ,, comment2 ,f can encompass "/*" , ,, */ R , or "//" 

without special meaning, and thus can encompass 
!5 a "commentl", "comment2" cannot be followed on 

the same line by other tokens, since it would be 
considered to encompass them, 

hexDiaitPair 

A pair of hexadecimal digits ( " 0" - n 9" , "A n - n F"). 

20 identifier 

Characters constrained as is the text of an 
identifier. 

numerals 

One or more numeral s { " 0 " - n 9 " ) 

25 5.3 Binary Telescripf 

A "binary telescript" is a procedure encoded as an 
octet string. The abstract syntactic rules for 
telescripts in general are made concrete for binary 
telescripts in particular in this section. 
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Each token in a binary telescript is one or more 
octets. The binary telescript is obtained by 
concatenating the tokens and thus the octets. 

5.3.1 Preface and Comment- 

5 Preface 

A preface obeys these rules: 
Preface : : = Version 

Version : : = unsignedNumber unsignedNumber 

The first and second "unsignedNumber" identify the 
10 major and minor versions, respectively, of the Instruction 
Set to which a character telescript conforms. 

Comment 

A comment obeys this rule : 

Comment : : = tag unsignedNumber characters 

15 The "unsignedNumber" is the number of octets to be 

recognized as characters. 

5.3.2 Executed Object-.? 

Bit 

A bit obeys these rules, which individually encode 
2 0 the bit's values: 

BitZero : : = tag 
BitOne : := tag 

BitStrir^q 

A bit string obeys these rules: 
25 BitString : := tag unsignedNumber unsignedNumber 

Octets 

Octets [octet Octets] 

The first "unsignedNumber" is the number- -in the 
range [1, 8] --of bits of the bit string in the last octet; 
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the other bits in that octet have no significance and are 
undefined. The second "unsignedNuraber" is the number, 
"n", of occurrences of the token "octet" in the token 
"Octets". If the octets are numbered in [1, n] , the bit 
5 whose position in the bit string is "i" is Bit (7-((i-l) 
mod 8)) of the octet numbered (l+(i-l)/8). 

Boolean 

A boolean obeys these rules, which individually 
encode the boolean' s values: 
10 BooleanFalse ::= tag 

Boolean True : : = tag 

Character 

A character obeys these rules. A general and a 
special encoding are defined. The latter shall be used 
15 for eight-bit characters: 

Character = GeneralCharacter | 
SpecialCharacter 

GeneralCharacter : := tag octet octet 
SpecialCharacter : : = tag octet 

20 The one or two octets encode unsigned the integer 

that is the character's Unicode code. In the special 
encoding, the MSB and LSB of the integer are those of the 
octet. In the general encoding, the MSB and LSB of the 
integer are the MSB of the first octet and the LSB of the 

25 second, respectively. 

Identifier 

An identifier obeys these rules. One general and two 
special encodings are defined. One of the latter shall be 
used iff the text of the identifier equals that of the 
30 identifier of a predefined class or feature: 
Identifier GenerallD | 

Predef inedClassID | 
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10 



15 



General ID 
Pr ede f inedCl ass ID 
Predef inedFeaturelD 



Predef inedFeaturelD 
= tag unsignedNumber characters 
= tag unsignedNumber 
= tag unsignedNumber 



5 In the general encoding, "unsignedNumber" and 

"characters" represent the text directly. The former is 
the number of octets to be recognized as the latter. In a 
special encoding, "unsignedNumber" represents the 
identifier's text indirectly, by a code drawn from one of 
10 the tables in section 5.4. 



20 



25 



30 



35 



Integer 

An integer obeys these rules. One general and 
several special encodings are defined. The latter shall 
be used for -1, 0, and +1: 



15 



20 



Integer 
General Integer 
Speciallnteger 



IntegerMinusOne 
IntegerZero 
IntegerPlusOne 



= General Integer | Speciallnteger 
= tag signedNumber 
= IntegerMinusOne | 

IntegerZero | 

IntegerPlusOne 
- tag 
= tag 
= tag 



The signedNumber is the integer. 



40 



Mark 

25 A mark obeys this rule: 

Mark : : = tag 



45 



50 



Modifier 

A modifier obeys these rules, which individually 
encode the modifier's values: 
30 Modif ierDemarcate tag 
Modif ierGetClass : : » tag 



55 
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Modi f ierGe t Property 
Modif ierGetVariable 
Modi f i erMent ion 
Modif ierSet At tribute 
Modif ierSet Property- 
Modi fierSetVariable 
Modif ierUseStack 



= tag 
= tag 
= tag 
= tag 
= tag 
= tag 
= tag 



10 



Nil 

A nil obeys this rule: 
Nil : := tag 



Octet 

An octet obeys this rule: 
Octet : : - tag octet 

The MSB of "octet" represents Bit 7 of the octet, the 
15 LSB Bit 0. 

OctetStrina 

An octet string obeys these rules: 

OctetString : : = tag unsignedNumber Octets 
Octets : : = [octet Octets] 

20 The "unsignedNumber" is the number of occurrences of 

"octet" in "Octets". The first "octet" in "Octets 0 
represents the octet at position one of the octet string, 
the second "octet" that at position two, etc. The MSB of 
each "octet" represents Bit 7 of that octet, the LSB 

25 represents Bit 0. 



Procedure 

A procedure obeys this rule : 

Procedure : : = tag unsignedNumber Body 
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The "unsignedNumber" encodes the number of 
occurrences of "ExecutedObject " in "Body", each of which 
encodes an item of the procedure. The items are given in 
order of increasing position within the procedure. 

5 Oualifie dldentifie-r 

A qualified identifier obeys this rule: 

Qldentifier ::= tag Identifier Identifier 

The first "Identifier" represents the text, the 
second represents the qualifier. 

10 Real 

A real obeys this rule: 

Real : := tag signedNumber signedNumber 

The first "signedNumber" is a mantissa, "m" , the 
second 

15 an exponent, "e". The real is m x I0 e . 



S^ectgr 




A selector obeys 


these 


encode the selector's 


values 


SelectorBreak 


: : = tag 


2 0 Selector Client 


: : = tag 


Selector Continue 


: : = tag 


Selector Escalate 


: = tag 


Selector Place 


: = tag 


Selector Process : 


: = tag 


25 Selector Self : 


: = tag 


Selector Succeed : 


: = tag 



String 

A string obeys this rule: 

String tag unsignedNumber characters 
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The "unsignedNumber" is the number of octets to be 
recognized as characters. The syntax and semantics of the 
octets shall conform to ISO/IEC 10646 [10646] compaction 
method 5, except that the characters thereby represented 
5 shall be limited to those of Unicode. 

Note : If the string comprises only ASCII characters, 

"characters" comprises their ASCII 
representations, one character per octet. Bit 7 
of each octet being zero. 

.0 5.3.3 Other Non- terminals 

Chayfrcfreys 
Zero or more octets . 

number 

From one to five, "N", octets encoding an integer, 
,5 "I". The encoding, "E n , of "I" is either unsigned, if the 
use of number insists that "I" be non-negative, or twos 
complement, otherwise. Given "I", "N" shall be as small 
as possible. 

"E" is determined as follows. 
0 • If the value of the first octet is in the range of 
[0, BF 16 ] , "N n is one and the MSB and LSB of "E n are 
Bit 7 and Bit 0 of that sole octet. 

• If the first octet is E0 I6 , E2 16/ E4 I6 , or E6 l6 , "N" is 

2, 3, 4, or 5 and the MSB and LSB of "E" would be Bit 
5 7 of the first octet and Bit 0 of the last octet if 

the first octet were made 00 16 . 

• If the first octet is El 16 , E3 16 , E5 16/ or E7 16 , N is 2, 

3, 4, or 5 and the MSB and LSB of "E w would be Bit 7 
of the first octet and Bit 0 of the last octet if the 

0 first octet were made FF l6 . 

Note: The first octet's values in the ranges of [C0 t6 , 

DF 16 ] and [E8 I6 , FF I6 ] are reserved. 

octet 
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One octet. 
sicmedNumber 

"number", where "I" can be positive or negative, and 
thus where w E n is signed (see above) . 
5 Note: If "N" is one, "I" is in the range [-64, 127]. 

If "N" is two, "I" is in the range [-128, 127] . 
If n N n is three, n I n is in the range [-32768, 
32767] . If »N" is four, "I" is in the range 
[-8388608, 8388607]. If »N" is five, "I" is in 
L0 the range [-2147483648, 2147483647] . 

tag 

"signedNumber" , where the tag's meanings are given in 
the next section. 

uns i gnedNumbe r 

.5 "number", where "I" is non-negative, and thus n E n is 

unsigned (see above} . 

NQte: If "N" is one, "I" is in the range [0, 191] . if 

"N" is two, "I" is in the range [0, 255] . If 
"N" is three, "I" is in the range [0, 65535]. 
0 if "N" is four, "I" is in the range [0, 

16777215] . If »N« is five, »I« is in the range 
[0, 4294967295] . 

5.4 Numeric Codes 

Binary telescripts make use of the following numeric 
5 codes . 

5.4.1 Predefined Classes 

Table A. 7 assigns identifier codes to the predefined 
subclasses of class "Executed 0 . 



TABLE A. 7 
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10 



35 



45 



1 


Bit 


2 


BitString 


3 


Boolean 


4 


Character 


5 


Identifier 


6 


Integer 


7 


Mark 


8 


Modifier 


9 


Nil 


10 


Octet 


11 


OctetString 


12 


Procedure 


13 


QI dent if ier 


14 


Real 


15 


Selector 


16 


String 


Table A. 8 assigns identifier codes to the other major 
predefined classes . 




TABLE 1,-8 


20 


Agent 


21 


Association 


22 


Attribute 


23 


Authenticator 



50 



55 



327 



BNSDOCID: <EP 063471 9A2 J_> 



EP 0 634 719 A2 



5 







24 


CalendarTime 






25 


Cased 


10 




26 


Citation 






27 


Cited 




5 


28 


Class 


15 




29 


CI as sDe f ini t ion 






30 


ClassException 


20 




31 


Collection 




32 


CollectionException 




10 


33 


Constrained 


25 




34 


ConstrainedDictionary 






35 


ConstrainedList 






36 


ConstrainedSet 


30 




37 


Constraint 




15 


38 


Contact 






39 


Contacted 


35 






Dictionary 






41 


Exception 






42 


Executed 


40 


20 


43 


Execut ionExcept ion 






44 








45 


Feature 


45 




46 


Hashed 






47 


Implementation 



50 
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5 







46 


I nt er changed 






49 


Interface 


10 




50 


KemelException 






51 


Lexicon 




5 


52 


List 


15 




53 


Means 






54 


Meet ingExcept ion 


20 




55 


MeetingPlace 




56 


Method 




10 


57 


Miscel laneous Except ion 


25 




58 


Named 






59 


Number | 






60 


Object 


30 




61 


Operation 




15 


62 


Ordered 






63 


Package 


35 




64 


Pattern 






65 


Permit 






66 


Petition 


40 


20 


67 


Petitioned 






68 


Place 






69 


Primitive 


45 




70 


Pr imi t i veExcept ion 






71 


Process 



50 
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5 









ProcessExcept ion 






•"7 *5 


ProgrammingException 


10 




/ *± 


RandomStream 






tc 
/ D 






c 
-j 


/ O 


Referenced 


15 




V7 








/ o 




20 




*7 Q 

/ y 


Resource 






q n 
o u 


Set 




i n 

JLU 


O J. 


Stack 


25 




Q O 
OA 


Stream 






O "5 


Teleaddress 






04 
o*± 


Telename 


30 




0 c 


Telenumber 




i ^ 
ij 


O D 


Ticket 






87 


TicketStub | 


35 




88 


Time 1 






89 


TripException 






90 


Unchanged 


40 


20 


91 


UnexpectedException 








92 


Unmoved 


45 




93 


Verified 




94 


Way 



Table A. 9 assigns identifier codes to the 
25 predefined classes. 
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5 




TABLE A. 9 






100 


Permi t I nadequa t e 




10 




101 


Argument I nval id 






102 


ArgumentMissing 




5 


103 


AttributeReadOnly 


15 




104 


ClassAbs tract 






105 


ClasaUnavailable 


20 




106 


ClassUndef xned 




107 


ClassSealed 




10 


108 


Condi t ionUnavai labl e 


25 




109 


Condi t i onUnde f i ned 






110 


Conve r s i onUnava i 1 abl e 






111 


CopyUnava i 1 ab 1 e 


30 




112 


DestinationUnavailable 




15 


113 


De s t i na t i onUnknown n 






114 


DivisionByZero 1 


35 




115 








116 


Escalat ionlnval id 






117 


Fea tureRede f ined 


40 


20 


118 


FeatureSealed 






119 


Fe a t u reUnava i 1 ab le 


45 




120 


Fea t ureUnde f ined 




121 


InternalException 






122 


ItemDuplicated 



50 
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123 


Itemlnvalid 






124 


KeyDuplicated 


10 




125 


Key Invalid 






126 


LoopMi s s ing 




5 


127 


MarkMissing 


15 




128 


MeetingDenied 1 






129 


MeetingDuplicated 






130 


Meetinglnvalid J 


20 




131 


MixinDiaal lowed 




10 


132 


Ob j ectsUnpaired 


25 




133 


Ob j ectuninit ial ized 




134 


OccupanyDenied 






135 


Passage Inval id 


30 




136 


Patternlnvalid 




15 


137 


Pe rmi t Exhaus t ed 






138 


Permi t Viol at ed 


35 




139 


PetitionExpired 






14 0 


Positionlnvalid 






141 


Proce s sNot Cur rent 


40 


20 


14 2 


ProcessNotPeer 






143 


Proper tyUndef ined 


45 




144 


Re f e rence Pro t ec ted 




145 


Reference Void 






146 


ResponderMissing 



50 
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147 


Result Invalid 


148 


ResultMissing 


149 


SelectorDuplicated 


150 


StackDepleted 


151 


St ate Improper 


152 


Superclasses Invalid 


153 


TicketExpired 


154 


VariableUnde fined 


155 


Way Unava i 1 ab 1 e 


179 


ResourceUnavailable 


180 


Seedlnvalid 


5.4.2 Predefined Features 


Table A. 10 assigns identifier codes to the predefined 
operations . 


T4VBfce At 1Q 


l 


abs 


2 


add 


3 


adjust 


4 


and 


5 


catch 


6 


ceiling 


7 


charge 


8 


clear 
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5 









TABLE A. 10 










convert 


10 




i fi 
x u 


copy 






11 


difference 






12 


discard 


15 


c 

■D 




divide 






1 A 


do 


20 




X 3 


drop 




16 


either 






X / 


entering 


25 


10 


18 


examine 




X -7 


exclude 






20 


exiting 


30 




-<£ X 


finalize 






22 


find 




15 


23 


floor 


35 




24 


get 






25 


globalize 






26 


go 


40 




27 


if 




20 


28 


include 






29 


initialize 


45 




30 


intersection 






31 


interval 



50 
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5 













32 


isAf ter 


10 




33 


isBefore 








34 


is Equal 


15 




35 


islnstance 


5 


36 


isMember 






37 


is Same 


20 




38 


isSubclass 






39 


live 






40 


localize 


25 


10 


41 


loop 






42 


makeClasses 






43 


makeLower 


30 




44 


makeUpper 






45 


meet 


35 


15 


46 


meeting 






47 


modulus 






48 


multiply 




40 




49 


negate 






50 


new 




20 


51 


normalize 


45 




52 


not 






53 


or 






54 


part 





50 



55 
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TABLE A- 10 






55 


part All 


10 




56 


parting 






57 


pop 


15 




58 


protect 


5 


59 


push 






60 


push I terns 


20 




61 


quotient 






62 


ref 






63 


rekey 


25 


10 


64 


repeat 






65 


reposition 






66 


restrict 


30 




67 


roll 






68 




round 




15 


69 


select 


35 




70 


send 






71 


set 






72 


stream 


40 




73 


substitute 




20 


74 


substring 


45 




75 


subtract 




76 


swap 






77 


terminate 



50 
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15 5 



20 



TABLE A. 10 


78 


throw 


79 


transpose 


80 


truncate 


81 


union 


82 


use 


83 


verify 


84 


wait 


85 


while 


86 


max 


87 


min 


Table A. 11 assigns identifier codes to the predefined 
attributes . 


TABLE A. 11 


89 


address 


90 


agentClass 


91 


a gent Name 


92 


allowance 


93 


arguments 


94 


authenticator 


95 


author 


96 


authority 


97 


brand 



55 
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5 



10 



20 



TABLE A. 11 


98 


canCharge 


99 


canGo 


100 


canProcreate 


101 


canRestart 


102 


canSend 


103 


canTerminate 


104 


citation 


105 


class 


106 


classFeatures 


107 


classld 


108 


classMethods 


109 


condition 


110 


conditions 


111 


constraint 


112 


contacts 


113 


country 


114 


current 


115 


day 


116 


dayOfWeek 


117 


dayOf Year 


118 


deadline 


119 


desiredWait 


120 


des t inat ionAddress 



55 



338 



BNSDOCID: <EP 063471 9A2 1 > 



EP 0 634 719 A2 



5 







TABIDS A. IX 






121 


destinat ionClass 


10 




122 


destinat ionName 






123 


destinat ionPermit 


15 




124 


digest 


5 


125 


dst . 






126 


exception 


20 




127 


exceptions 






128 


extension 






129 


fromMethods 


25 


10 


130 


hash 






131 


hour 






132 


identity 


30 




133 


i implementation 






134 


instance Features 


35 


15 


135 


instanceMethods | 




136 


interface 






137 


isAbs tract 


40 




138 


is Done 






139 


is Lower 




20 


140 


isOptional 


45 




141 


isProtected 






142 


isPublic 






143 


isSet 



50 
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TABLE ft- 11 






144 


* ^» \* \f 


10 




145 








146 




15 




14 7 


lucaL ion 


5 


148 


m = ~i nrPH t t- -i 

HW* J CiUl L. XUil 






149 


iiiox i mum Wei it 


20 




150 








151 


m inor aqi c ion 






152 


itiinuue 


25 


10 


153 








154 


Alctuic 






155 


n.6xt 


30 




156 








157 


passage 


35 


15 


158 


permit 




159 


priority 






160 


privateClasses 


40 




161 


procedure 

... . 






162 


properties 




20 


163 


provider 


45 




164 


publicClasses 






165 


result 






166 


rout ingAdvice 



50 
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TABLE A. 11 






i. D / 


sealedClassFeatures 




10 




loo 


sealedlnstanceFeatures 






ICQ 


setMethods 






1 /U 


second 


15 


5 


1 fx 


size 






i to 


subject 


20 




J. / J 


subject Class 








1 "7 A 


sub j ectName 






1 7C 
X /D 


subjectNotes 


25 


10 


I/O 


superclasses 






177 


telephone 






I/O 


ticketStub 


30 




179 


title 






180 


toMethods 




15 


181 


travelNotes 


35 




182 


value 






183 


variables 






184 


vocabulary 


40 




185 


way 




20 


186 


year 








187 


zone 




45 











Note: "islnstance" is not listed as an attribute 

because it is also an operation. 

50 
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Table A. 12 assigns codes Co the forms of passage . 



TABLE A. 12 




191. 


byCopy 




192 


byProtectedRef 




193 


byRef 




194 


byUnpro t ec t edRe f 




5.4.3 Executed 


Obiect Encodinas 




Table A. 13 assigns codes to general -purpose 
encodings . 




TABLE A. 13 


1 




2 


BitString 


3 


_ 


4 


General Character 


5 


Identifier 


6 


General Integer 


7 


Mark 


8 




9 


Nil 


10 


Octet 


11 


OctetString 


12 


Procedure 


13 


Qualif iedldentif ier 
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TABLE A. 13 


14 


Real 


15 




16 


String 



Note : These tags are the codes for the corresponding 

5 predefined classes. 

Table A. 14 assigns codes to special -purpose encodings 
of a basic nature. 



TABLE A. 14 


0 


Comment 


-1 


Bit Zero 


-2 


BitOne 


-3 


BooleanFalse 


-4 


BooleanTrue 


-5 


SpecialCharacter 


-6 


Predef inedClassIdent if ier 


-7 


Predef inedFeatureldentif ier 


-8 


IntegerMinusOne 


-9 


IntegerZero 


-10 


Integer PlusOne 


Table A. 15 assigns codes to special -purpose encodings 
of modifiers. 


j TABLE A. 15 
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10 



-12 


Modif ierDemarcate 


— 1 J 


nuui J- iciocLLiaoo 


-14 


Modi f ie rGe t Prope r ty 


-15 


Modif ierGetVariable 


-16 


Modif ierMent ion 


-17 


Modif ierSetAttribute 


-18 


Modif ierSet Property 


-19 


Modif ierSetVariable 


-20 


Modif ierUseStack 



25 10 Table A. 16 assigns codes to special -purpose encodings 

of selectors. 





TABLE A. 16 


-21 


SelectorBreak 


-22 


SelectorClient 


-23 


SelectorContinue 


-24 


SelectorEscalate 


-25 


SelectorPlace 


-26 


SelectorFrocess 


-27 


SelectorSelf 


-28 


SelectorSucceed 



45 

6 Syntax of Module 

A "module", as the term is used here, is a string 
that encodes one or more interfaces, the identifiers of 

so 
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the classes of which those interfaces are parts, and, 
finally, an identifier for the module itself. 

Throughout Section 6, the term "identifier" 
implicitly refers to the text of an instance of class 
5 "Identifier", rather than to the instance as a whole. 
Note : A module constructed as described below is a 

High Telescript module as well. Any rule below 
that makes this statement false is a 
documentation error . 

10 6.1 General Structure 

A module is a series of tokens obeying the syntactic, 

and accompanying semantic, rules below. Given in BNF, the 

rules surround optional tokens by brackets ("[" and "]"). 

In addition, a module can include comments of the sort 
15 permitted in a character telescript . The provision for 

such comments is considered among the syntactic rules 

governing the module . 

Each token is one or more characters- The module is 

obtained by concatenating the tokens, and thus the 
20 characters, and by inserting between tokens break 

characters of the sort permitted in a character 

telescript . 

Keywords, e.g., "module", are case -sens it ive . While 
upper- case characters are used below to describe modules 
25 in general, lower-case characters are used in Section 7 
and throughout this appendix to construct a module. 

6 - 2 Detailed Structure 

A module exhibits the following detailed structure. 

6.2.1 Module 
30 Module 

A module obeys these rules : 

Module ; := identifier : MODULE = 

(Interfaces) 
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Interfaces 
[Interfaces] 



;= identifier : Interface; 



The module is denoted by the identifier that begins 
the module, and encodes the interfaces, each that of the 
5 class whose identifier immediately precedes the 
identifier . 

Any interface can define operation "initialize" as i 
Pertains to members of the interface's particular class. 
A definition is implied, furthermore, if none is stated: 
10 either "initialize: op ();", if the class in question is 
mix-in, or the definition for the flavor among the class' 
interface superclasses, otherwise. 



6-2.2 Interface 
Interface 
15 An interface obeys 

Interface : : = 



) 

2 0 Formal Parameters 

Forma 1 Par ame t ere Jroup 
Superclasses 
Definitions 
Definiti onGroup 



25 



Access 
Responder 
Identifiers 
Definition 



these rules: 

[SEALED j ABSTRACT] INTERFACE 
" ["FormalParameters ,! ] n ] 
[Superclasses] - ( [Definitions] 

ParameterGroup [ ; 
Identifiers : CLASS 

{ [ClassSpecif iers] ) 
DefinitionGroup ; [Definitions] 

[Access] [Responder] 
Identifiers : Definition 
PUBLIC | PRIVATE | SYSTEM 
INSTANCE | CLASS 
identifier [, Identifiers] 
SEALED | [SEALED ( ABSTRACT] 



3 0 Feature 



An interface's encoding can be parameterized. In 
such an encoding, one or more "formal class parameters 1 
each an identifier, are introduced, and can be used in 
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most places the interface requires class identifiers (see 
token "ClassSpecif ier" below) . The interface is as if the 
identifier of class "Object" were used instead. Formal 
class parameters defined alike are grouped at their 
5 introduction. 

Zero or more features, each denoted by an identifier, 
are sealed or defined. The identifiers of features sealed 
or defined alike are grouped. If "Access 0 or "Responder" 
is absent from the first such group, "PRIVATE" or 

10 " INSTANCE" , respectively, shall be considered present 
there. If "Access" or "Responder" is absent from any 
subsequent group, the keyword present in the previous 
group shall be considered present in the subsequent group. 
The interface is this. The "classFeatures" or 

15 "instanceFeatures" attribute comprises the features 
defined in groups with "CLASS" or " INSTANCE" , 
respectively. The "isAbs tract" attribute is "true" iff 
"ABSTRACT" is present. The "sealedClassFeatures" or 
"sealedlnstanceFeatures" attribute comprises the 

20 identifiers in groups with both "SEALED" and "CLASS" or 
"INSTANCE", respectively. The "superclasses" attribute 
comprises either the identifiers token "Superclasses" 
determines, if the latter is present, or the identifier of 
Class "Object" only, otherwise. The positions in the 

25 attribute of the classes decrease as their specifiers move 
from left to right. The "vocabulary" attribute is 
cleared. 

The interface is sealed iff "SEALED" is present. 

6.2.3 Feature 
30 Feature 

A feature definition obeys this rule: 

Feature ::= Attribute | Operation 

Attribute 

An attribute definition obeys this rule: 
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Attribute : : = [READONLY] Constraint 
[THROWS Identifiers] 
The attribute definition is this. The "constraint" 
attribute is the constraint given. The "exceptions" 
5 attribute comprises either the identifiers present, if 
"THROWS" is present, or no identifiers, otherwise. The 
"isPublic" attribute is "true" iff the key for the 
definition group that includes the attribute definition is 
"PUBLIC" or "CLASS". The "isSet" attribute is true iff 
10 "READONLY" is absent. 

A module's encoding, as defined above, of an 
attribute definition is sometimes called the signature of 
the attribute it defines. 

Operation 

15 An operation definition obeys this rule: 

Operation : : = [UNPROTECTED] op ( 

ArgumentsAt tribute ) 
[Constraint] [THROWS Identifiers] 
The operation definition is this- The "arguments" 

2 0 attribute is as given. The "exceptions" attribute 

comprises either the identifiers present, if "THROWS" is 
present, or no identifiers, otherwise. However, iff 
" UNPROTECTED " is present, the attribute comprises, 
additionally, the identifier for class "Reference 
25 Protected", which is thrown if the operation, which 
modifies the responder, is requested using a protected 
reference to the responder. The "isPublic" attribute is 
"true" iff the key for the definition group that includes 
the operation definition is "PUBLIC" or "CLASS" (see token 

3 0 "Interface" above) . The "result" attribute is either the 

constraint, if one is present, or a nil, otherwise. 

A module's encoding, as defined above, of an 
operation definition is sometimes called the signature of 
the operation the operation definition defines. 
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Arcrume ntsAttribute 

An "arguments" attribute obeys these rules: 
ArgumentsAttribute : : = [Arguments] [ . . . ] 

Arguments ::= ArgumentGroup [; Arguments] 
5 ArgumentGroup ::= Identifiers : Constraint 

Zero or more arguments are described by their 
constraints. Each such argument is denoted by an 
identifier. The identifiers of arguments constrained 
alike are grouped. If both one or more argument groups 
10 and the ellipsis (...) are present , the last group shall 
comprise just one argument, but shall be considered to 
comprise zero or more arguments . 

The "arguments" attribute is either a list of the 
constraints upon the zero or more described arguments, if 
15 the ellipsis (...) is absent, or a nil, otherwise. The 
positions, in the list, of the constraints upon the 
described arguments increase as their identifiers move 
from left to right. 

6.2.4 Constraint 
20 Constraint 

A constraint obeys these rules : 

Constraint : : = [COPIED | PROTECTED | 

UNPROTECTED] ClassSpecif ier [" | " 
NIL] 

25 The constraint is this. The "classld" attribute is 

the identifier that token "ClassSpecif ier" determines. 
The "islnstance" attribute is "true" iff the exclamation 
mark ("!") is present within token "ClassSpecif ier" (see 
below). The "isOptional " attribute is "true" iff "NIL" is 

30 present. The "of Class" attribute is a nil. The "passage" 
attribute is "byCopy", "byProtectedRef " , 
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"byUnprotectedRef ° , or "byRef" if "COPIED", "PROTECTED", 
" UNPROTECTED " , or none of these, respectively, is present. 

ClassSoecifier 

A class specifier obeys these rules: 
ClassSpecif ier identifier [!] 

[" [•' ClassSpecif iers "] " ] 
ClassSpecif iers : := ClassSpecif ier [, 
ClassSpecif iers] 

The identifier is that of either a formal class 
10 parameter or a class, "C". In the latter case, iff the 
encoding, "E", of the interface of "C" is parameterized, 
there follow, between square brackets ("[" and "]"), as 
many actual class parameters, each a class specifier, as 
n C" has formal class parameters. This particular use of 
15 "C" is as if each use of a formal class parameter within 
"E" were a use of the correspondingly positioned actual 
class parameter. 

6.2.5 Other Non- terminal a 

identifier 

20 Characters constrained as is the text of an instance 

of class "Identifier". 



7 PREDEFINED MODULE 

The interfaces to the predefined classes are defined 
by a module which appears in full below and in fragments 
25 throughout this appendix. The Instruction Set's internal 
features do not appear in the module. 

This Section, i.e. Section 7, provided for reference 
purposes, duplicates material found elsewhere in this 
appendix . 

3 0 Note: The predefined interface definitions form a High 

Telescript module. To make this possible, 
certain Low Telescript identifiers are postfixed 
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55 



with "j" to avoid identifiers that are reserved 
words in High Telescript * 



10 



15 



Telescript 
Agent : 



module = { 

abstract interface (Process) = ( 
private 

go: unprotected op (ticket: copied 

Ticket) TicketStub 
throws PermitViolated, 

State Improper , Tr ipExcept ion ; 



20 



25 



10 



15 



send: unprotected op (tickets: 

copied List [Ticket] ) 

TicketStub | Nil 
throws PermitViolated, 

Statelmproper, Tr ipExcept ion; 



) ; 



30 



35 



40 



45 



50 



20 



25 



Association : 



Attribute : 



sealed interface [keyClass, valueClass 
Class] (Object, Ordered) « ( 
public 

key: keyClass ; 

value : valueClass ; 
system 

initialize: unprotected op ( 
key: keyClass; 
value: valueClass) ; 

) ; 



sealed interface (Feature) = 
public 

constraint : Constraint ; 

isSet : Boolean; 



( 
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10 



system 

initialize: unprotected op ( 
constraint : Constraint j Nil ; 
isSet, isPublic: Boolean [Nil 
except ions : Set 



[Identifier!] (Nil) 



) ; 



15 



Authenticator : abstract interface = () ; 



20 



25 



10 (); 



Bit: sealed interface (Primitive, Ordered) 



BitString: sealed interface (ConstrainedList 

[Bit] , Executed) * { 
public 

constraint : sealed; 



30 



35 



15 



system 



initialize: unprotected op 
(segments : Object . . . 
/* Bit (protected BitString! */) ; 



) ; 



20 Boolean: sealed interface (Primitive, Ordered) 

40 ( public 

and, or: op (boolean: Boolean) 

Boolean; 



45 



25 



not : op { ) Boolean ; 



) ; 



50 



CalendarTime : interface = ( 

public 
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day, dst, hour, minute, month, 
second, year, zone: 
Integer | Nil ; 

dayOfWeek, dayOf Year : readonly 
Integer { Nil ; 



O ; 



globalize, localize : unprotected op 



Boolean; 



10 



normalize: unprotected op () 



) ; 



Cased: abstract interface () ( 
public 

isLower, isUpper: abstract 
readonly Boolean ; 



15 



makeLower, makeUpper: abstract op 
() copied Cased; 



); 



20 



Character: sealed interface (Primitive, Cased, 
Ordered) = () ; 

Citation: interface (Object, Ordered) = ( 
public 

author : Telename | Nil ; 



Integer | Nil ; 



majorEdition, minorEdition: 



25 



title: Identifier! ; 
system 

initialize: unprotected op ( 
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10 



15 Citation; 
10 



20 



25 



30 



35 



40 



title : Identifier ! ; 
author: Telename j Nil ; 
ma j orEdi t ion , minorEdi t ion : 
Integer | Nil) ? 

) ; 

Cited: abstract interface () » ( 
public 

citation: readonly protected 



20 



45 



50 

30 



55 



system 

initialize: unprotected op ( 
title: Identifier! ; 
majorEdition, minorEdi t ion: 

Integer) ; 

15 ); 

Class: sealed interface (Object, 

Cited, Interchanged) = ( 
public 

convert: sealed op (source :- 
protected Object) 
copied Object 
throws Conver s ionUna vail able; 

islnstance: sealed op (instance_x: 
protected Object) Boolean; 

isMember: sealed op (member: 
protected Object) Boolean; 

isSubclass: sealed op (subclass: 
Class) Boolean; 

new: sealed op (parameters: Object 
. . . ) Object 



25 
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10 



throws ClassAbs tract, Exception, 
ObjectUninitialized; 

system 

initialize: unprotected op {) 
throws FeatureUnavailable ; 



) ; 



15 



ClassDef inition: sealed interface = ( 

public 

implementation: 

10 Implementation | Nil ; 



20 



interf ace_x : Interface ; 



25 



30 



Integer; 



15 



majorEdition, minorEdition : 



makeClasses : op (definitions; 

protected ClassDef inition 

Lexicon [Class] 
throws ClassException; 



35 



40 



45 



20 



25 



minorEdition : Integer; 



Implementation | Nil) ; 

> ; 



title: Identifier! ; 
system 

initialize: unprotected op (title: 
Identifier I ; 
ma j orEdi t ion , 

interf ace_x: Interface; 
implementation : 



50 



ClassException: abstract interface 
(ProgrammingException) = (); 
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ClassSealed: interface (ClassException) 

= () ; 

ClassUndef ined : interface 
(ClassException) == () ; 

FeatureRedef ined: 

interface (ClassException) = () ; 
FeatureSealed: interface 

(ClassException) = () ; 
FeatureUndef ined: 
10 interface (ClassException) = {); 

MixinDisallowed : 

interface (ClassException) - (); 
Superclasseslnvalid: 

interface (ClassException) = {) ; 

15 Collection: interface [itemClass: Class] =( 

public 

clear: unprotected op () ; 

examine: op (item: protected 
itemClass) itemClass |Nil; 



20 



exclude: unprotected op (item: 
protected itemClass) 
itemClass |Nil; 



itemClass) 



25 



include: unprotected op (item: 

throws Itemlnvalid; 
length: readonly Integer ; 



30 



stream: op () copied Stream 
[itemClass] ; 

system 

initialize: unprotected op (items; 
itemClass . . . ) 
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10 



15 



20 



25 



30 



35 



40 



t hro ws I t em Inva 1 i d ; 



) ; 



Collection abstract interface 
( ProgrammingExcept ion ) = ( ) ; 
5 Exception: ItemDuplicated : 



10 



15 



20 



25 



Constrained: 



Constraint I Nil ) 



interface (Collect ionExcept ion) 
Itemlnvalid: 

interface (CollectionException) 
KeyDuplicated : 

interface (CollectionException) 
Key Invalid: 

interface (CollectionException) 
Ob j ectsUnpaired : 

interface (CollectionException) 
Posit ionlnvalid: 

interface (CollectionException) 
StackDepleted : 

interface (CollectionException) 

abstract interface () = ( 
public 

constraint : 
readonly protected Constraint; 
system 

initialize: unprotected op ( 
constraint : copied 



) ; 



45 



50 



Constrained 
Dictioncary : 



30 



interface [keyClass, valueClass: Class] 
(Dictionary [keyClass, valueClass] , 

Constrained) = ( 

system 

initialize: unprotected op ( 

constraint: copied Constraint; 
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10 



) ; 



keysAndValues : Object ... 
/* key: keyClass; value: 
valueClass */) 
throws KeyDuplicated, Keylnvalid, 
Ob j ectsUnpaired ; 



ConstrainedList 



15 



20 



25 



Cons t r a i nedS e t 



30 



35 



interface titemClass: Class] (List 
[itemClass] , Constrained) = ( 
system 

initialize: unprotected op ( 
constraint: copied Constraint; 
items : itemClass . . . ) 
throws Itemlnvalid; 

) ; 

interface [itemClass: Class] 

(Set [itemClass] , Constrained) = ( 
system 

initialize: unprotected op ( 

constraint: copied Constraint; 
items : itemClass . . . ) 
throws ItemDupl icat ed , 
Itemlnvalid; 

) ; 



40 



45 



50 



Constraint : 



interface = ( 
public 

classld: Identifier! ; 

islnstance, isOptional: Boolean; 
of Class: readonly Class {Nil; 
passage : Identifier ! 
throws Passagelnvalid; 
system 

initialize: unprotected op ( 
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Identifier! jNil; 
Boolean ! Nil) 



Contact : 



Contacted : 



classld, passage: 
isOptional , islnstance : 
throws Passage Inval id ; 



); 



interface = ( 
public 

sub j ect : Process | Nil ; 
subjectClass: readonly protected 

Citation { Nil ; 
subjectName: readonly protected 

Telename | Nil ; 
sub j ectNotes : Ob j ect | Nil ; 

system 

initialize: unprotected op ( 
sub j ect : Process j Nil ; 
sub j ectNotes ; Object) Nil) ; 

) ; 

abstract interface () = ( 
private 

contacts : readonly Set [Contact] ; 

) / 



Dictionary: interface [keyClass, valueClass : Class] 

(Set [Association [keyClass, 

valueClass] ] ) = ( 
public 

add: unprotected op (key: keyClass ; 

value : valueClass) 
throws Keylnvalid; 
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drop: unprotected op (key: protected 

keyClass ) valueClass 
throws Keylnvalid ,- 

find: op (value: protected 
valueClass) keyClass |Nil; 

get: op (key: protected keyClass) 

valueClass 
throws Key Invalid ; 

rekey: unprotected op ( 

currentKey: protected keyClass; 

ne wKey : keyCl as s ) 
throws Keylnvalid; 

set: unprotected op ( 

key: protected keyClass; 
value : valueClass ) 

throws Keylnvalid; 

transpose: unprotected op (keyl, 

key2: protected keyClass) 
throws keylnvalid; 
system 

initialize: unprotected op 

(keysAndValues : Object . . . 
/* key: keyClass; value: valueClass */) 
throws KeyDuplicated, Keylnvalid, 

Ob j ectsUnpaired ; 

) ; 

abstract interface (Object, Unchanged) = 
(public 

throw_x: sealed op {) ; 

) ; 
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10 



15 



20 



25 



10 



15 



30 



Executed: abstract interface () = ( 
public 

catch_x : sealed op (exception: 

Class) Exception | Nil 
throws Exception; 

do_x, loop_x: sealed op () 
throws Exception; 

either: sealed op (false_x: 
Executed; precondition: Boolean) 
throws Exception; 

if_x: sealed op (precondition: 
Boolean) 

throws Exception; 

repeat_x: sealed op (repetitions; 
Integer) 

throws Exception ; 



35 



40 



45 



50 



20 



() ; 



Exception: 



25 



30 



while_x: sealed op (precondition: 
Executed) 

throws Exception, Result Invalid, 
ResultMissing; 



) ; 



Execution abstract interface (KernelException) = 



Argument I n va lid: 

int er f ace ( Execut ionExcep t ion ) 
Argument Mi s s i ng : 

interface (ExecutionException) 
AttributeReadOnly : interface 

(ExecutionException) = () ; 



= 0 ; 
= 0; 
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10 



20 



25 



ClassUnavailable : 

interface (ExecutionException) = () ; 
Escalat ionlnvalid : 

interface (ExecutionException) = () ; 
5 FeatureUnavailable : 

interface (ExecutionException) = {) ; 
InternalException : 

interface (ExecutionException) - {) ; 
15 Property Undefined: 

10 interface (ExecutionException) o () ; 

Ref erenceProtected : 

interface (ExecutionException) = () ; 
Ref erenceVoid : 

interface (ExecutionException) = () ; 
15 ResponderMissing: 

interface (ExecutionException) = () ; 
Result Invalid: 

interface (ExecutionException) « () ; 
ResultMissing : 

20 interface (ExecutionException) = () ; 

VariableUndef ined : 

interface (ExecutionException) ■ () ; 

35 Feature: abstract interface = ( 

public 

25 exceptions: Set [Identifier!]; 

40 isPublic : Boolean; 

system 

initialize: unprotected op ( 
isPublic : Boolean (Nil; 
45 30 exceptions: Set 

[Identifier!] |Nil) ; 

) ; 



30 



50 



Hashed: abstract interface () = ( 
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public 

5 hash: abstract readonly Integer; 

) ; 

Identifier: sealed interface (Primitive, Ordered) : 

10 5 { ) ; 

Implementation: sealed interface = ( 

public 

classMethods , f romMethods , 
instanceMethods , setMethods, 
10 toMethods: Lexicon [Method] ; 



15 



20 



properties: List [Identifier!]; 



superclasses : List 
25 [Identifier!] |Nil; 

vocabulary: Lexicon 
15 [Citation] (Nil; 

30 system 

initialize: unprotected op ( 
superclasses : List 
[Identifier!] |Nil; 
35 20 vocabulary: Lexicon 

[Citation] |Nil; 
properties: List 
m [Identifier!] |Nil; 

instanceMethods , setMethods , 
25 classMethods, 

f romMethods, toMethods: Lexicon 
45 [Method] | Nil) ; 

) ; 

Integer: sealed interface (Number) = ( 
so 3 0 public 
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modulus, quotient: op (divisor; 
Integer) Integer 
5 throws DivisionByZero; 

) ; 

io 5 Interchanged: abstract interface (Unchanged) = ( 

public 

digest: abstract readonly 
protected Object |Nil ; 

15 ) ; 

10 Interface: sealed interface = ( 

public 



20 



15 



30 



35 



20 



40 



SO 



classFeatures , inst ancePeatures : 
Lexicon [Feature] ; 



25 isAbstract: Boolean; 



sealedClassFeatures , 

sealedlnstanceFeatures : 
Set [Identifier!] ; 

superclasses: List [Identifier!]; 

vocabulary: Lexicon [Citation]; 
system 

initialize: unprotected op ( 
superclasses : List 
[Identifier!] {Nil; 
vocabulary: Lexicon 



45 25 [Citation] |Nil; 



instanceFeatures : 

Lexicon [Feature] |Nil; 
sealedlnstanceFeatures : 

Set [Identifier!] |Nil ; 
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classFeatures : Lexicon 
[Feature] |Nil; 
sealedClassFeatures : 

Set [Identifier!] jNil; 
isAbstract: Boolean) Nil) ; 

) ; 

Kernel 

Exception; abstract interface 

( ProgrammingExcept ion) = () ; 

ClassAbstract : interface 
(KernelException) = () ; 

ConversionUnavailable : 

interface (KernelException) = (); 

CopyUnavailable : 

interface (KernelException) = () ; 

LoopMissing : interface (KernelException) 

= ( ) ; 

MarkMissing: interface (KernelException) 

= () ; 

Obj ectUninitialized: 

interface (KernelException) = () ; 

Pas sage I nva 1 id : 

interface (KernelException) s () ; 

SelectorDuplicated: 

interface (KernelException) « () ; 

Lexicon: interface [valueClass: Class] 
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10 



(ConstrainedDictionary [Identifier, 

valueClass] ) = ( 
public 

constraint : sealed ; 
system 

initialize: unprotected op 

(keysAndValues: Object ... 
/* key: Identifier!; value; 
is valueClass */) 

throws KeyDuplicated, Keylnvalid, 
ObjectsUnpaired; 



10 



15 

25 



) ; 

20 

List: interface [itemClass: Class] 

(Collection [itemClass] , Ordered) 
= ( 
public 

add: unprotected op (position: 
Integer ; item : itemClass ) throws 
30 Itemlnvalid, Positionlnvalid; 

drop: unprotected op (position: 
Integer) itemClass 
35 throws Positionlnvalid; 

find: op ( 

initialPosition: Integer; 
item: protected itemClass) 
Integer | Nil 
throws Positionlnvalid; 



40 



25 



45 

30 

50 



get: op (position: Integer) 
itemClass 

throws Positionlnvalid; 
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15 



30 



reposition: unprotected op 

(currentPosition, newPosition : 
Integer) 

throws Positionlnvalid; 

set: unprotected op (position: 
Integer; item: itemClass) throws 
1 1 emlnva 1 id , Pos i t i on I nval id ; 



transpose : unprotected op 
(positionl, position2: Integer) 
10 throws Positionlnvalid; 

20 system 

initialize: unprotected op (items 
itemClass . . . ) ; 

) ; 

25 

15 Mark: sealed interface (Primitive) = () ; 

Means: abstract interface = () ; 

Meet ingExcept ion: abstract interface (Exception) = () ; 

35 MeetingDenied : 

interface (Meet ingExcept ion) =(); 
20 Meet ingDupli cat ed: 

interface (MeetingException) = (); 
40 Meetinglnvalid: 

interface (MeetingException) = () ; 
PetitionExpired : 

45 25 interface (MeetingException) = () ; 

MeetingPlace: abstract interface (Place) = ( 

public 

50 
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meet: unprotected op (petition: 
copied Petition) Contact 

throws Meet ingExcept ion, 
ProcessNotCurrent , 
State Improper ; 

part: unprotected op (contact: 
Contact) 



15 throws Meetinglnvalid, 

ProcessNotCurrent , 
Stat e Improper; 



10 



20 



25 



30 



35 



45 



10 



part All: unprotected op () 
throws ProcessNotCurrent , 
Statelmproper ; 

) ; 

15 Method: sealed interface = ( 

public 

procedure : Procedure ; 

variables: List [Identifier!] ; 
system 

20 initialize: unprotected op ( 

procedure : Procedure | Nil ; 
variables: List 

40 [Identifier!] |Nil) ; 

)/ 

25 Miscellaneous abstract interface 

(ProgrammingException) = () ; 
Exception: 

Pat t ernlnval id : interface 
50 (MiscellaneousException) = () ; 
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Seedlnvalid: 

interface (MiscellaneousException) 

() ; 

Modifier: sealed interface (Primitive) = (); 

Named: abstract interface () = ( 
public 

name : sealed readonly protected 



is Telename; 



= ( 



Number; 



) ; 

Nil: sealed interface (Primitive) = (); 
Number: abstract interface (Primitive, Ordered) 
public 

abs, negate: abstract op () 



add, multiply: abstract op 
( number : Numbe r ) Numbe r ; 

35 

ceiling, floor, rotind, truncate: 
abstract op () Integer; 

40 divide: abstract op (divisor: 

Number) Number 
throws DivisionByZero; 



45 



50 



subtract: abstract op (subtrahend: 
Number ) Number ; 



) ; 



Object: abstract interface (Referenced) = ( 
public 
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class: sealed readonly Class; 
copy: sealed op () copied Object 

throws CopyUnavailable; 

isEqual: op (object: protected 
Object) Boolean ; 

select: sealed op (associations: 
Object . . . 

/* protected Object; Executed 
*/) 

throws Exception, 

SelectorDuplicated; 

size: sealed readonly Integer ; 
system 

finalize, initialize: unprotected 
op () ; 

) ; 

Octet: sealed interface (Primitive, Ordered) = 

OctetString: sealed interface (ConstrainedList 

[Octet] , Executed) « ( 
public 

constraint : sealed ; 
system 

initialize: unprotected op 
(segments: Object ... 
/* Octet (protected OctetString! 
*/) ; 

) ; 
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Operation; sealed interface (Feature) = ( 

public 

arguments: List [Constraint] [Nil 

result : Constraint j Nil ; 
system 

initialize: unprotected op ( 
arguments : List 

[Constraint] |Nil; 

result : Constraint | Nil; 
isPublic : Boolean | Nil ; 
exceptions: Set 

[Identifier!] |Nil) ; 

) ; 

Ordered: abstract interface {) = ( 
public 

isAfter, isBefore: abstract op 
(object: protected Ordered) 

Boolean; 
max, min: op (object: Ordered) 

Ordered; 

) ; 

Package: interface (ConstrainedSet [Class], 
Cited, Interchanged) = ( 
public 

constraint : sealed; 
system 

initialize: unprotected op ( 
title : Identifier ! ; 
ma j or Edi t ion , minorEdi t ion : 
Integer ; 

items : Class . . . ) 
throws ItemDuplicated, 
ProcessNo t Peer ; 



371 



EP 0 634 719 A2 



) ; 

5 

Pattern: interface (Object, Ordered) = ( 
public 

find: op (string: protected 
10 5 String!; position: Integer (Nil) 

List [Integer] |Nil 
throws Positionlnvalid; 
substitute: op ( 

repetitions : Integer; 
10 string: unprotected Strings- 

replacement: protected String!) 
20 Integer 

system 

initialize: unprotected op (text: 
15 copied String!) 

throws Patternlnvalid; 

) ; 



15 



25 



30 

20 

35 



40 



Permit: interface (Object, Ordered) » ( 
public 

age, authenticity, charges, 

extent, priority: Integer! Nil; 

canCharge , canCreate , canDeny , 
canGo, canGrant , canRestart , 
canSend : Boolean ; 

25 intersect: op (permit: Permit) 

Permit ; 

system 

initialize: unprotected op (age, 
charges , extent : Integer | Nil ) ; 

so 

30 Petition: interface = ( 
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public 

agentClass : Citation | Nil ; 



10 



15 



10 



) ; 



agentName : Telename | Nil ; 

maximumWait : Integer | Nil ; 
system 

initialize: unprotected op ( 
agentName: Telename | Nil ; 
agentClass: Citation (Nil; 
maximumWait : Integer | Nil) ; 



20 



25 



15 



Petitioned: 



abstract interface 0 = ( 
system 

meeting: unprotected op ( 

contact: Contact; petition: 
protected Petition) 
throws MeetingDenied; 



30 



35 



20 



) ; 



parting: unprotected op (contact: 
Contact) ; 



Place: abstract interface (Process, Unmoved) = 



40 



public 

address: sealed readonly protected 
Teleaddress; 



45 



25 



publicClasses: sealed readonly Set 
[Cited] ; 



50 



terminate: sealed unprotected op ( 
occupant: protected Telename) 
Boolean 
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throws ProcessNotCurrent , 

ProcessNotPeer, State Improper 

system 

entering: unprotected op { 

contact : Contact ; 

permit: protected Permit; 

ticket: protected Ticket (Nil) 
throws OccupancyDenied; 

exiting: unprotected op ( 
contact : Contact ; 
permit: protected Permits- 
ticket: protected Ticket (Nil); 



Primitive : 



abstract interface (Object, Executed, 
Unchanged) « ( 
system 

initialize: unprotected op () 
throws FeatureUnavailable; 

) ; 



Primitive abstract interface 
(ProgrammingException) = () ; 
Exception: 

Di vis ionByZero : interface 

(PrimitiveException) = () ; 

Procedure: sealed interface (Primitive) = (); 



Process : 



abstract interface (Object, Named, 
Uncopied) =( 
public 

brand: sealed readonly protected 
Object 

throws ProcessNotPeer ; 
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localPermit: sealed copied Permit 
throws FeatureUnavailable, 
PermitViolated ; 



10 



nativePermit : sealed copied Permit 
throws FeatureUnavailable , 
PermitViolated; 



15 



Permit ; 



permit : sealed readonly copied 



throws ProcessNotPeer; 



20 



25 



10 



Permit 



regional Permit : sealed copied 

throws FeatureUnavailable , 
PermitViolated ; 



30 



15 



private 

age: sealed readonly Integer ; 



35 



Set [Process] ; 



charges: sealed readonly Integer; 



contacts: sealed readonly 



40 



20 



45 



50 25 



priority: sealed Integer | Nil; 

privateClasses : sealed readonly 
Set [Cited] ; 

public 

charge: sealed op (charges: 

Integer) 
throws Permit Inadequate , 

PermitViolated; 



55 



375 



EP 0 634 719 A2 



restrict_x: sealed op ( 
procedure : Procedure ; 
permit: protected Permit) 

throws Exception, PermitViolated, 
ProcessNotCurrent ; 

sponsor_x: sealed op { 
procedure : Procedure ; 
permit: protected Permit) 

throws Exception, PermitViolated, 
ProcessNotCurrent ; 

wait: unprotected op (seconds: 
Integer) ; 

system 

initialize: op ( 

nativePermit : copied Permit; 
privateClasses : Set 
[Cited] | Nil) 
throws PermitViolated ; 

live: abstract unprotected op 

(cause: Exception | Nil) 
throws Exception; 

restricted: op (permit: 

Identifier; isRelocated: 
Boolean) PermitReduced j Nil ; 

) ; 

Process - abstract interface 

(ProgrammingException) = () ; 

Exception: 

Permitlnadequate : interface 
(ProcessException) « () ; 
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Condi tionUnavail able : 

interface (ProcessException) = (); 

ConditionUndef ined : 

interface (ProcessException) = (); 

PermitExhausted : 

interface (ProcessException) = {)/ 

Permi tViolated : 

interface (ProcessException) = (); 

ProcessNotCurrent : 

interface (ProcessException) = {); 

ProcessNotPeer : 

interface (ProcessException) = () ; 



ResourceUnavailable : 
30 interface (ProcessException) = (); 

15 State Improper : 

interface (ProcessException) = () 



Programming abstract interface (Exception) = () ; 
Exception: 

Qualified sealed interface (Identifier) = {) ; 
2 0 Identifier: 



RandomStream: interface (Stream [Integer]) = ( 

system 

initialize: unprotected op (seed: 

Integer) 
throws Seedlnvalid; 

) ; 
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Real: sealed interface (Number) = {) ; 

Referenced: abstract interface {) = ( 

public 

discard: sealed op () ; 

isProtected: sealed readonly 
Boolean; 

isSame: sealed op (reference: 

protected Referenced) Boolean; 

protect: sealed op {) protected 
Referenced; 



ref_x: sealed unprotected op () ; 



) ; 



Resource: interface = ( 
so public 

15 condition: Identifier! 

throws ConditionUnavailable; 



35 



40 



conditions: readonly protected Set 
[Identifier!] ; 

use: sealed unprotected op { 
20 procedure : Procedure ; 

exclusive : Boolean | Nil ; 
maximumWait : Integer j Nil ; 
45 conditions: copied Set 

[Identifier!] |Nil) Boolean 

25 throws Condi tionUnde fined, 

50 

Exception, ResourceUnavailable; 

system 
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initialize: unprotected op ( 
5 condition: Identifier! [Nil; 

conditions: copied Set 

[Identifier!] |Nil) throws 
5 ConditionUndef ined; 

10 ) ; . 

Selector: sealed interface (Primitive) = () ; 



15 



Set: interface [itemClass: ClassJ 

(Collection [itemClass] , Verified) 
10 ( 

20 public 

difference, intersection, union: 
unprotected op (set; protected Set 
[itemClass] ) ; 

25 15 system 

initialize: unprotected op (items: 
itemClass . . . ) 

^ throws ItemDuplicated, Itemlnvalid; 



2 0 Stack: 

35 



40 

25 



45 



SO 



) ; 



interface [itemClass: Class] (List 
[itemClass] ) = ( 
public 

pop: unprotected op () itemClass 
throws StackDepleted; 

push: unprotected op (item: 
itemClass) ; 

pushltems: unprotected op ( 
items: protected List 
[itemClass] ) ; 
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roll: unprotected op (shifts, 

items : Integer) 
throws Argument Invalid, 
StackDepleted; 

swap : unprotected op ( ) 
throws StackDepleted; 

) ; 

Stream: abstract interface [itemClass: Class] 

( 

public 

current: abstract readonly 
itemClass {Nil; 

isDone: abstract Boolean; 

next: abstract readonly 
itemClass |Nil 

throws Ref erenceProtected; 

) ; 

String; sealed interface 

(ConstrainedList [Character] , Cased, 

Executed) » ( 
public 

constraint : sealed; 

substring: op (initialPosition, 
beyondFinal Posit ion : Integer) 
copied String 

throws Positionlnvalid; 
system 

initialize: unprotected op 
(segments : Object . . . 
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/* Character {protected String! 
*/>; 



) 



Teleaddress : 



interface = ( 
public 

location : String ! j Nil ; 



provider : OctetString ! ; 

routingAdvice : List 
[OctetString! ] ; 
system 

initialize: unprotected op ( 
provider: OctetString! |Nil; 
location: String 1 jNil) ; 



) 



Telename: interface = ( 
public 

authority: OctetString! ; 

identity: OctetString! (Nil; 
system 

initialize: unprotected op ( 
au t hor i ty , ident i ty : 
OctetString! jNil) ; 

) ; 



Telenumber : 



interface = ( 
public 

country, telephone: String! ; 



extension : String ! | Nil ; 
system 
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initialize: unprotected op ( 
countryAndTelephone : String ! ; 
extension: String! |Nil) ; 



) ; 



Ticket: interface (TicketStub) = ( 
public 

desiredWait, maxiraumWait : 
Integer | Nil; 

destinationAddress : 
Teleaddress | Nil ; 

destinationClass: Citation [Nil ; 

dest inat ionName : Telename | Nil ; 

destinat ionPermit : Permit { Nil ; 
system 

initialize: unprotected op ( 

destinationName : Telename | Nil; 
destinationAddress : 
Teleaddress | Nil ; 
destinationClass : Citation | Nil ; 
maxitnumWait : Integer j Nil ; 
way: Way {Nil ; 
travelNotes : Object | Nil ) ; 

) ; 



TicketStub: 



interface = { 
public 

travelNotes : Obj ect | Nil ; 



way: Way | Nil ; 
system 

initialize: unprotected op ( 
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way; Way [Nil ; 
travelNotes: Object|Nil) ; 

) ; 

Time: interface (Object, Ordered, Unchanged) 
( 

public 

adjust: op (seconds: Integer) Time; 
interval: op (subtrahend: Time) Integer 
) ; 

TripException: abstract interface (Exception) = ( 

public 

ticketStub: sealed TicketStub; 
system 

initialize: unprotected op 
(ticketStub: TicketStub) ; 

) ; 

DestinationUnavailable : 

interface (TripException) « () ; 

De s t ina t i onUnknown : 

interface (TripException) = (); 

OccupancyDenied : 

interface (TripException) = () ; 

TicketExpired: interface (TripException) 
= (); 

WayUnava ilable : interface 
(TripException) = () ; 

Unchanged: abstract interface () = () ; 
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Unexpected: interface (ExecutionException) = ( 
Exception: public 

exception: readonly Exception ; 
system 

5 initialize: unprotected op ( 

exception: Exception) ; 

) ; 

Unmoved: abstract interface () = () ; 

Verified: abstract interface 0 = ( 
10 public 

verify: abstract op () Boolean,* 

) ; 



Way: interface = ( 
25 public 

15 authenticator: Authenticator |Nil ; 

means : Means | Nil ; 



20 



name : Te 1 ename | Ni 1 ; 
system 

initialize: unprotected op ( 
name : Telename j Nil ; 
means : Means | Nil ; 
authent icator : 
Authenticator (Nil) ; 

); 

25 ) /* Telescript */ 



8 PREDEFIN ED CLASS GRAPH 

The diagram below shows the part of the class graph 
involving the predefined classes. The immediate 
subclasses of a class lie indented just below it. Classes 
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which are underlined are abstract. Parentheses ("(" and 
" )" ) enclose mix-ins. 
Object ( Referenced ) 

Association ( Ordered ) 
Authenticator 
Calendar Time 
Citation ( Ordered ) 
Class ( Cited & Interchanged ) 
Class Definition 
Collection 

List ( Ordered ) 

• Constrained List ( Constrained ) 

• • Bit String ( Executed ) 

• • Octet String ( Executed ) 

• • String ( Cased & Executed ) 

• Stack 
Set ( Verified ) 

• Constrained Set ( Constrained ) 

• • Package ( Cited & Interchanged ) 

• Dictionary 

• • Constrained Dictionary ( Constrained ) 

• • • Lexicon 
Constraint 
Contact 

Exception ( Unchanged ) 

Meeting Exception 
Programming Excep t ion 
Class Exception 
Col lect ion Excep t i on 
Kernel Exception 

• Execution Exception 

• • Unexpected Exception 
Misce llaneous Exception 
Primiti ve Excep t- -ion 
Process Excep tion 

Trip Exception 
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Feature 
• Attribute 
Operation 
Implementation 
Interface 
Means 
Method 

Pattern ( Ordered ) 
Permit ( Ordered ) 
Petition 

Primitive (Executed & Unchanged ) 

• Bit ( Ordered ) 

• Boolean ( Ordered ) 
Character ( Cased & Ordered ) 
Identifier ( Ordered ) 

• Qualified Identifier 
Mark 
Modifier 
Nil 

Number ( Ordered ) 

• • Integer 

• • Real 

• Octet ( Ordered ) 

• Procedure 

• Selector 
Process (Named) 

• Agent 

• Place ( Unmoved ) 

• • Meeting pi 
Resource 

Stream 

• Random Stream 
Teleaddress 
Telename 
Telenumber 
Ticket Stub 



• 
• 
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• Ticket 

• Time ( Ordered & Unchanged ) 

• Way 

Cased 

5 Cited 

Constrained 

Contacted 

Executed 

Hashed 

15 10 Named 

Ordered 

Petitioned 

Referenced 
20 

Unchanged 
15 • I nt er changed 
Unmoved 
25 Verified 
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APPENDIX B 

Copyright @ General Magic, Inc. 1991, 1992, 1993. All 
Rights Reserved 

The following Table of Contents is to assist the 
5 reader in understanding the organization of and locating 
information within this appendix. 

is Table of Contents 

1 INTRODUCTION 

1.1 Organization 
10 1.2 References 

20 

2 ENCODING CONCEPTS 
2 . l Teleparcel 

2.2 Object Encoding 
25 2.2.1 Forms 

15 2.2.2 Rules 

2.2.3 Palettes 

2.2.4 Encoding Classes 

2.2.5 Encoding Attributes 

2 . 3 Attribute Encoding 
20 2.3.1 Forms 

35 2.3.2 Rules 

2 . 4 Reference Encoding 

2.4.1 Forms 

2.4.2 Rules 
25 3 ENCODING SPECIFICATIONS 

3 . 1 Conventions 

3 . 2 Teleparcel 

3.3 Object Encoding 
3.3.1 Executed Object 

30 3.3.2 Predefined Object 

3.3.3 User-defined Object 

3.3.4 Protected Object 

3.3.5 Palette 
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3.4 Attribute Encoding 

3.4-1 Boolean 

3.4.2 Dial String 

3.4.3 Integer 
5 3.4.4 Item 

3.4.5 List 

3.4.6 Octet String 

3.4.7 Stack 

3.4.8 String 

15 10 3-5 Reference Encoding 

3.5.1 General Reference 

3.5.2 Voided Reference 

3.5.3 Interchange Reference 

3.5.4 Class Reference 
15 3.5.5 Procedure Reference 

4 ENCODING CLASSES AND ATRRIBUTES 

4 . 1 Conventions 

4.2 Encoding Group 
4.2.1 Catch Frame 

20 4.2.2 Collection Stream 

4.2.3 Dial String 

4.2.4 Frame 

4.2.5 Go Frame 

35 4.2.6 Predefined Frame 

25 4.2.7 Procedure Frame 

4.2.8 Repeat Frame 

4.2.9 Restrict Frame 

AO 

4.2.10 Send Frame 

4.2.11 Use Frame 

30 4.2.12 User-defined Frame 

45 4.2.13 While Frame 

4 . 3 Encoding Attributes 

4.3.1 Agent 

so 4.3.2 Catch Frame 

35 4.3.3 Collection 

4.3.4 Collection Stream 
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4.3.5 Dictionary 

4.3.6 List 

4.3.7 Pattern 

5 

4.3.8 Procedure Frame 
5 4.3.9 Random Stream 

4.3.10 Repeat Frame 
10 4.3.11 Restrict Frame 

4.3.12 Send Frame 

4 . 3 . 13 Stack 
10 4.3.14 Time 

4.3.15 Use Frame 

4.3.16 User-defined Frame 

4.3.17 While Frame 
5 ENCODING PALETTES 

i5 5.1 Conventions 

5 . 2 Language Classes 

5.2.1 Agent 

5.2.2 Association 

5.2.3 Attribute 

2 0 5.2.4 Calendar Time 

5.2.5 Citation 

5.2.6 Class 

5.2.7 Class Definition 
35 5.2.8 Collection 

25 5.2.9 Constrained Dictionary 

5.2.10 Constrained List 

5.2.11 Constrained Set 

5.2.12 Constraint 

5.2.13 Contact 

3 0 5.2.14 Dictionary 

45 5.2.15 Implementation 

5.2.16 Interface 

5.2.17 Lexicon 

5.2.18 List 
35 5.2.19 Method 

5.2.20 Mix-in 
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5.2.21 Operation 

5.2.22 Package 

5.2 .23 Pattern 

5 . 2 . 24 Permit 

5 5.2.25 Petition 

w 5.2.26 Random Stream 

5.2.27 Resource 

5.2.28 Set 

5.2.29 Stack 

15 

10 5.2.30 Teleaddress 

5.2.31 Telename 

5.2.32 Telenumber 
20 5.2.33 Ticket 

5.2.34 Ticket Stub 

15 5.2.35 Time 

5.2.36 Trip Exception 

25 5.2.37 Unexpected Exception 

5.2.38 Way 

5.3 Encoding Classes 

20 5.3.1 Catch Frame 

30 

5.3.2 Collection Stream 

5.3.3 Predefined Frame 

5.3.4 Repeat Frame 

35 5.3.5 Restrict Frame 

25 5.3.6 Send Frame 

5.3.7 Use Frame 

5.3.8 User-defined Frame 

40 

5.3.9 While Frame 



1 , INTRODUCTION 

45 3 0 Section 1 of Appendix A of this disclosure introduces 

the major elements of the present invention and that 
discussion is incorporated herein by reference. The 
conventions described in Section 1.4.3 of Appendix A are 

50 followed in this appendix as well. 
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1 - 1 Organization 

This appendix is divided into three sections. 
Section 1 is this introduction. Section 2 introduces the 
Encoding Rules' major concepts. Section 3 defines the 
5 predefined classes and attributes beyond those in the 
Instruction Set — that are used in encoding. 

References 

This appendix relies upon these other documents: 
[10646] 

Information technology Universal C o ded Charar^*- 
Set (UCS), ISO/IEC DIS 10646, International Organization 
for Standardization and International Electrotechnical 
Commission, 1990. 

[Telescript] 
15 Appendix A of this disclosure. 

[Unicode] 

Tfre Unicode Standa rd: World w id e Character Encoding. 
Volume 1, Version 1.0, The Unicode Consortium, 
Addison-Wesley, 1991 . 

20 2 ENCODING COKTCEPTfi 

Teleparcels are conceived in this section of this 
appendix. Subsections are devoted to teleparcels and to 
object, attribute, and reference encodings. 

2 . 1 Teleparcel 
25 A "teleparcel" encodes an object, which is the 

teleparcel's -subject " , the subject's components, and all 
of their components, recursively. The class of the 
subject or any component can be either predefined or 
user-defined. 

30 Note: A teleparcel is a Telescript object in its 

canonical form. 
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Note: A teleparcel is the means by which an object is 

transported between two Engines. A source 
Engine transforms an object into a teleparcel 
and transports it to a destination Engine. The 
latter transforms the teleparcel into an object, 
thereby producing at the destination the same 
object consumed at the source. 

Note : A teleparcel 's subject is typically, although 

not exclusively, an agent. In such cases, the 
teleparcel encompasses the agent and all the 
objects the agent owns, including those that 
make up the agent's current execution state. 

2 . 2 Obi ec t Encoding- 

An "object encoding" encodes an object and a 
reference to the object. 

2.2.1 Forms 

An object encoding assumes one of these forms: 

Executed 

An "executed object encoding" encodes an executed 
object . 

Predefined 

A "predefined object encoding" encodes an unexecuted 
object whose class is predefined. 

User-defined 

A "user-defined object encoding" encodes an object 
whose class is user-defined. 



Protected 

A "protected object encoding" encodes an arbitrary 
50 object. 
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15 4 



Encoding an object also encodes a reference to ^ 
o^ect. The reference is protected iff Lth« the ob 
x. unchan ged or the objecfc t J^£L£? 

2-?2.2 Rules 

5 The form of the object encoding f or an object an , 

reference, shall be selected <„ =, „ object, and a 
ftvii„ ■ . sexected in accordance with the 
followxng rules, appl ied in the order given 

1. A protected object encoding shall be selected if the 
reference M protected and the object is not 

10 unchanged. 

2. object encoding shaU be selected if che 
object is executed. 

A Predefined object encoding shall be selected if tne 
class of the object is predefined. ^ 

L™r d object ~- ~" - — 

pal. t «. 0b i eC \"'' 00din9 ^ UPOn - "-coding 

object is an »examol e .. of ! ' ° ^""P 1 *- An 

25 object is an ilT * Predefined <=^ss iff the 

an exa mp ie ls : o C : ^ ^ <*« °* "hich -o- is 

Each „ strained, or named. 

Each predefined attribute i n = 
either mandatory or • i P * ±S desi 9nated 

shall be reprlsIntL * ' ,mandat °^" attribute 

represented in an encoding that draws upon the 
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palette, while an "optional" attribute may, but need not, 
be represented. A number is assigned, for encoding 
purposes, to each optional attribute. 
Note: No object is an example of a mix-in. 

5 2.2.4 Encoding Classes 

The encoding palettes admit encoding classes as 
described in Section 4.2 of this appendix. An "encoding 
class" is a predefined class beyond the "language 
classes" which are classes described in Appendix A of this 
10 disclosure that supports the Instruction Set for 

encoding purposes but is not part of the Instruction Set. 
Not£: An encoding class' only purpose is to define 

encoding attributes. Such a class has no 
initialization parameters, operations, 
15 adaptations, or conversions. 

2-2.5 Encoding Attribute 

The encoding palettes admit encoding attributes as 

described in Section 4.3 of this appendix. An "encoding 

attribute" is a predefined attribute beyond the 
20 "language attributes" which are described in Appendix A of 

this disclosure that supports the Instruction Set for 

encoding purposes but is not part of the Instruction Set. 

Every encoding attribute is a system instance attribute. 

Note: An encoding attribute does not preclude the 

25 interface of a user-defined class from providing 

an attribute with the same identifier. 

2 ■ 3 Attribute Encoding 

An "attribute encoding" encodes a predefined 
attribute and a reference to the attribute. 

30 3.3.1 Forms 

An attribute encoding assumes one of these forms: 
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Boolean 

A "boolean attribute encoding" encodes an instance of 
class "Boolean" . 

Dial String 

5 A "dial string attribute encoding" encodes an 

instance of class "Dial String" . 

Integer 

An "integer attribute encoding" encodes an instance 
of class "Integer". 

10 Item 

An "item attribute encoding" encodes an object or a 
reference to the object. 

List 

A "list attribute encoding" encodes an instance of 
15 class "List". 

Octet String 

An "octet string attribute encoding" encodes an 
instance of class "Octet String". 



Stack 

L H S3t-saf-lr 2*4-+-^-,* a 

s an instance of 



20 a "stack attribute encoding" encode 



class "Stack" . 
String 

A "string attribute encoding" encodes an instance of 
class "String". 

25 2.3.2 Rules 

The form of the attribute encoding for an attribute 
shall be selected in accordance with the following rules. 



applied in the order 



given : 
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1 . An attribute encoding other than an item attribute 
encoding shall be selected if the attribute is an 
instance of the required class . 

2. An item attribute encoding shall be selected 
5 (otherwise) . 



2 . 4 Reference Encoding 

A "reference encoding" encodes a reference to an 
object that is encoded by an object encoding. 

2.4.1 Forms 
10 A reference encoding assumes one of these forms: 

General 

A "general reference encoding" encodes a (protected 
or unprotected) reference that denotes an object by means 
of the "offset" in octets from the start of the reference 
15 encoding to the start of the object encoding. The offset 
is positive or negative if the object's encoding follows 
or precedes the reference's, respectively. Offsets shall 
be negative; positive offsets are reserved. 

Voided 

2 0 A "voided reference encoding" encodes a reference 

that is voided. 



Interchange 

An "interchange reference encoding" encodes a 
reference that denotes an interchanged object by means of 
25 both the object's digest and a citation to the class of 
which the object is an instance. 

Class 

A "class reference encoding" encodes a reference that 
denotes a class by means of either the class' numeric 



397 



EP 0 634 719 A2 



code, if the class is predefined, or a citation to the 
class, if the class is user-defined. 

Procedure 

A "procedure reference encoding" encodes a reference 
5 to a procedure that is in the implementation of a 

user-defined class. A procedure reference encoding shall 
be used to encode only the "procedure" attribute of a 
predefined frame, F. A procedure reference encoding 
expresses, by means of an integer, the procedure's 

10 position in the "procedure" attribute of the procedure 
frame, "B», just below "F" in the "frames" attribute of 
which "F" is an item. The integer is either the position 
itself, if the integer is greater than or equal to one, or 
one plus the arithmetic difference between the position, 

15 the minuend, and the "position" attribute of F, the 
subtrahend, otherwise . 



20 



2.4.2 Rules 

The form of the reference encoding of a reference to 
an object shall be selected in accordance with the 
following rules, applied in the order given: 

1. A voided reference encoding shall be selected if the 
reference has been voided. 

2. A class reference encoding shall be selected if the 
object is a predefined class. 

25 3. A general reference encoding shall be selected if the 
object is encoded as part of the teleparcel, rather 
than presumed present at the teleparcel 's 
destination . 

4. A class or procedure reference encoding shall be 

3 0 selected if the object is a user-defined class or a 

procedure in a user-defined class implementation, 
respectively. 

5. An interchange reference encoding shall be selected 
(otherwise) . 
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Note: 



Thus Rule 3 applies iff the object is encoded as 
part of the teleparcel, rather than presumed 
present at the teleparcel' s destination. 

1 ENCODING SPErTPTriTTfiKTO 

5 Teleparcels are defined in this section of this 

appendix. Subsections are devoted to teleparcels and to 
object, attribute, and reference encodings. 

\3_JL ConvenHnnn 

A teleparcel is a series of tokens, each of which is 
10 zero or more octets. The teleparcel is the octet string 
obtained by concatenating the tokens. 

A teleparcel obeys the syntactic, and accompanying 
semantic, rules below. Given in BNF (Backus-Naur or 
Backus normal form) , the rules surround optional tokens by 
15 brackets ("[» and "]'»). 

Table B.l assigns codes to the forms of object and 
reference encoding. These codes are used as tags in the 
sections below. 



TABLE B1 
- 5 0 Procedur eRe f e r ence 

-51 InterchangeReference 

-52 UnprotectedReference 

-53 PredefinedClassReference 

-54 ProtectedReference 

- 55 Protect edObj ect 

-56 - 

-57 - 

-58 UserDefinedClassReference 

-5a VoidedReference 

-60 Mixins 
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Note : The sections below follow the conventions of 

Sections 5-1 and 5.3 of Appendix A of this 
disclosure. 

3 . 2 Teleparcel 
5 A teleparcel obeys this rule: 

Teleparcel ::= unsignedNumber unsignedNumber Object 

The first and second "unsignedNumber" encode the 
number of the major and minor versions of the Encoding 
Rules to which the teleparcel conforms, respectively . 
10 "Object" encodes the teleparcel 's subject and the 
sub j ect ' s components . 

Note : The numbers of the major and minor versions of 

the Encoding Rules that this appendix defines 
are 0 and 5, respectively. 

15 3 ■? Object Encoding 

An objects encoding obeys this rule, which reflects 
the defined forms: 

Object ::= ExecutedObject | PredefinedObject 

| UserDef inedObject | ProtectedObject 

20 3.3.1 Executed Object 

An executed object encoding obeys the rule set out in 
Sectins 5.1 and 5.3 of Appendix A of this disclosure. 

The tag that is the first token in "ExecutedObject" 
identifies the object as executed and reveals the object's 
25 class by encoding twice the class' code. 

Note: An executed object is encoded as in a binary 

telescript . 

3.3.2 Predefined Object. 

A predefined object encoding obeys this rule: 
30 PredefinedObject tag Palette 
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The tag identifies the object as predefined and 
reveals the object's class by encoding twice the class' 
code. The "Palette" draws upon the primary encoding 
palette for the class of which the object is an example. 

5 3.3.3 User-defined Object 

A user-defined object encoding obeys this rule: 
UserDef inedObject [Palette Mixins] tag Item Item 

Palette Mixins : : = tag 

The first "tag" identifies the object as user-defined 
10 and reveals the class of which the object is an example by 
encoding one plus twice the class' code. 

The first "Item" encodes the object's class, the 
second a list whose items correspond to the user-defined 
implementation superclasses of that class in their 
15 canonical order. Each item is itself a list, a list of 
the properties of the instance native to the class to 
which the item corresponds, in the order of their 
identifiers in the "properties" attribute of the class' 
implementation. The final one or more properties can be 
2 0 omitted, in which case nils are implied. 

The first "Palette" draws upon the secondary encoding 
palette and is present iff "Mixins" is present. The 
second "Palette" draws upon the primary palette for the 
class of which the object is an example. 

25 3.3.4 Protected Object 

A protected object encoding obeys these rules: 
ProtectedObject : := tag ProtectedObject Itself 



ProtectedObject Itself : := ExecutedObject 



45 Predef inedObject | 

30 UserDef inedObject 
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The "tag" identifies the reference as protected. The 
"ExecutedObject", the "Predef inedObject , or the 
"UserDefinedObject" encodes the object. 

3 - 3 -5 Palette 
5 An encoding palette's encoding obeys these rules: 

Palette : := Attributes [Mask Attributes] 

unsignedNumber 
[Attribute Attributes] 



Mask 
Attributes 



The first "Attributes" encodes the zero or more 
10 attributes that the palette declares mandatory, in the 
order in which they are listed in the table that defines 
the palette. The table fixes the number of occurrences of 
"Attribute" . 

The "Mask" and the second -Attributes" are present 
15 iff the palette declares any attributes optional. The 
second "Attributes- encodes zero or more of the optional 
attributes. The "Mask" fixes the number of occurrences of 
"Attribute". 

The "Mask" encodes an integer indicating which 
20 optional attributes the second "Attributes" encodes. The 
palette's table numbers the optional attributes in the 
range of [1, n] . The second "Attributes" includes an 
encoding of the attribute numbered "i" iff the bit in the 
integer's representation weighted 2" is one. The 
25 attributes actually encoded appear in the second 

"Attributes" in order of increasing "i". Bits logically 
required by "n" but physically absent from "Mask" shall be 
considered zero. Bits physically present but logically 
not required shall be ignored. 



30 2^4. Attrihi^ e EnmrHng 

An attribute encoding obeys this rule, which reflects 
the defined forms: 
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Attribute ::= Boolean j DialString | 

Integer ( 

Item | List j OctetString | 

String 

5 3.4.1 Boolean 

A boolean attribute encoding obeys this rule: 
Boolean ::= empty 

The boolean attribute encoding is present iff the 
boolean is "true". 
10 Note: The encoding's presence is indicated by the mask 

that encompasses the encoding. 
Note; Thus a palette's boolean attributes are 

necessarily optional. 

3.4,2 Dial Strino 

15 A dial string attribute encoding obeys this rule; 

DialString OctetString 



The "OctetString" encodes the octet string, n O", 
determined by the list, "L" f of nibbles determined in turn 
by the dial string, "D", and having the same length. 
20 A nibble of "L" encodes unsigned the integer in the 

range [0, 14] determined by the character of "D" at the 
same position. The numerals <"0"-"9 H ) determine 0-9, a 
dash ('»-") determines 13, and a space {" ") determines 14. 
40 The nibble of "L" at position 2i-l or 2i, »i" being at 

25 least one, occupies Bits 7-4 or 3-0, respectively, of the 
octet of "0" at position »i». Bit 7 or 3, respectively, 
is the MSB, Bit 4 or 0, respectively, the LSB. Iff the 
length of "D" and thus "L» is odd, Bits 3-0 of the last 
octet of "0" encode 15 in the same way. 
30 Note : Thus a dial string is encoded in a form of 

Binary Coded Decimal (BCD) . 



so 
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3.4.3 Integer 

An integer attribute encoding obeys this rule: 
Integer : : = signedNumber 

The "signedNumber" encodes the integer. 
5 Note : This is a binary telescript encoding of an 

integer, except that the initial token, 
identifying the encoding as an integer's general 
encoding, is absent. 



3.4.4 Item 
10 An item attribute encoding obeys this rule: 

20 Item ::= Object | Reference 

The "Object" or "Reference" encodes the object or a 
reference to the object, respectively. 



3.4.5 List 
15 A list attribute encoding obeys these rules: 

List ::= unsignedNumber Items 

Items [Item Items] 

The "unsignedNumber" and "Items" together encode the 
list. The former encodes the number of occurrences of 
20 "Item" in the latter, which in turn encode the items of 
the list in order of increasing position. 

3-4.6 Octet String 

An octet string attribute encoding obeys this rule: 
OctetString : : = unsignedNumber Octets 

25 The "unsignedNumber" and "Octets" together encode the 

octet string as specified in Section 5.3.2 of Appencix A 
of this disclosure. 

Note: This is a binary telescript encoding of an octet 

string, except that the initial token. 
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10 



15 



identifying the encoding as an octet string's, 
is absent . 

3.4.7 Stack 
A stack attribute encoding obeys the same rules as a 

5 list attribute encoding, except that the items of the 
stack are encoded in order of decreasing position. 

3.4.8 String 
A string attribute encoding obeys this rule: 

String : : = unsignedNumber characters 

20 10 The "unsignedNumber" and "characters" together encode 

the string as specified in section 5.3.2 of Appendix A of 
this disclosure . 

Note : This is a binary telescript encoding of a 

string, except that the initial token, 
15 identifying the encoding as a string's, is 

absent . 



25 



30 



35 



40 
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3-5 Reference Encoding 

A reference encoding obeys this rule, which reflects 
the defined forms: 
20 Reference :: = GeneralRef erence | 

VoidedRef erence | 
InterchangeRef erence j 
ClassRef erence | 
ProcedureRef erence 

25 3.5.1 General Reference 

A general reference encoding obeys these rules. One 
encoding is defined for unprotected references, another 
for protected references: 

GeneralRef erence UnprotectedRef erence | 

30 ProtectedRef erence 

UnprotectedRef erence : : = tag signedNumber 
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ProtectedRef erence ::= tag signedNumber 

The "tag" identifies the general reference as such 
and as either unprotected or protected. The 
"signedNumber" encodes the offset from the reference 
encoding to the object encoding of the referenced object 

3.5.2 Voided Reference 

A voided reference encoding obeys this rule: 
VoidedRef erence : := tag 

The -tag" identifies the voided reference as such. 

3.5.3 Interchange Reference 

An interchange reference encoding obeys this rule: 
InterchangeRef erence : : = tag Item Item 

The "tag" identifies the interchange reference as 
such. The first "Item" encodes a citation to the 
interchanged object's class. The second "Item" encodes 
the interchanged object's digest. 



3.5.4 Class Reference 

35 A class reference encoding obeys these rules. One 

encoding is defined for predefined classes, another for 
user-defined classes: 

ClassRef erence ::= Predef inedClassRef erence | 

UserDef inedClassRef erence 
Predef inedClassRef erence ::= tag unsignedNumber 

UserDef inedClassRef erence ::= tag Item 

The "tag" identifies the class reference as such and 
the class as either predefined or user-defined. If the 
class is predefined, the "unsignedNumber" encodes the code 
assigned to the class either in Section 5.4.1 of Appendix 
A of this disclosure or in Table B.2, below, of this 
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appendix. If the class is user-defined, the "Item" 
encodes the class' citation. 

3.5.5 Procedure Reference 

A procedure reference encoding obeys this rule: 
5 ProcedureReference ::= tag signedNumber 

The "tag" identifies the procedure reference as such. 
The "signedNumber" identifies the procedure's position as 
previously described. 

4. ENCODING CLASSES AND ATTRIBUTES 
.0 Telescript's encoding classes and attributes are 

defined in this section of this appendix. A subsection is 
devoted to first the encoding of classes and then the 
encoding of attributes . 

4 . 1 Conventions 
5 Encoding Classes 

The encoding classes form a group. The section below 
that defines this group follows the conventions, e.g., of 
Section 3.2 of Appendix A of this disclosure. 

Table B.2 assigns identifier codes to the encoding 
0 classes . 



TABLE B.2 
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CatchFrame 




145 


Collect ionSt ream 


146 




147 


Predef inedFrame 


148 


Go Frame 


149 


Repeat Frame 


150 


RestrictFrame 
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10 



151 


SendFrame 


152 


UseFrame 


153 


UserDef inedFrame 


171 


While Frame 



15 5 Note : 



20 



25 



Note : 



10 



Classes "Frame" and "Procedure Frame" require no 
codes because they are abstract. Class "Dial 
String" requires no code because its instances 
have their own encodings. 

Because an encoding class' only purpose is to 
define encoding attributes, this appendix does 
not devote a major section to each encoding 
class, even though Appendix A devotes such a 
section, e.g., Section 4.2 to every language 
class . 



30 



35 



40 



15 Encoding Attributes 

The encoding attributes are native to certain 
language and encoding classes. The section below that 
defines the encoding attributes devotes a subsection to 
each predefined class to which such attributes are native, 

20 The classes are considered in alphabetical order. An 
encoding attribute's definition follows the conventions 
established in Section 4.1 of Appendix A of this 
disclosure . 

Note: Identifier codes need not be assigned to the 

25 encoding attributes. 



45 



50 



4^2. Encodin g Group 
Ob j ec t ( Ref e renced ) 

• Collection 

• • List (Ordered) 

30 # • • Constrained List (Constrained) 
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String {Cased & Executed) 
• Dial String 



10 



15 



• • • • 

Frame 

• Procedure Frame 

• • Predefined Frame 

• • • Catch Frame 

• • • Repeat Frame 

• • • Restrict Frame 

• • • Use Frame 

• • • While Frame 

• • User-defined Frame 

• go Fyame 

• • Send Frame 
Stream 

• Collection Stream 



4.2.1 Catch Frame 
Attributes 

exception 

A "catch frame" is a predefined frame whose subject 
2 0 method is the method for "catch" and whose "procedure" 
attribute is the operation's responder. 

A catch frame's native attribute is the class that is 
the operation's argument (attribute "exception") . 

4.2.2 Collection Stream 
25 Attributes 

position 
source 

A "collection stream" is a stream whose items are 
those of a collection. 
30 A collection stream's native attributes are the 

stream's source (attribute "source") and the stream's 
current position (attribute "position" ) . The "source" is 
the collection whose items the collection stream produces. 
The "current position" is a position in the "items" 
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10 



attribute encoding the collection stream's source. The 
collection stream last produced the item at the stream's 
current position, previously produced any items at 
positions before the current position, and has yet to 
produce any items at positions after the current position. 
Note: A collection stream is the result of the 

"stream" operation when the latter is performed 
by a collection. 

4.2.3 Dial String 
A "dial string" is a string each item of which is 

either a numeral <"0"-"9">, a hyphen ("-"), or a space {» 
") . 

HQJtS: Dial strings are used in telenumbers. 

4.2.4 Frame 

15 A "frame" is an object recording the current state of 

a performance of a predefined or user-defined method, the 
frame ' s n sub j ect method" . 

4.2.5 Go Frame 

A "go frame" is a frame entailing the taking of a 
2 0 trip. The method is the predefined method for either 
operations "go" or "send", the former in the case of an 
instance of this class, the latter in the case of an 
instance of this class' subclass. 

4-2.6 Predefined Frame 

2 5 A "predefined frame" is a procedure frame whose 

subject method is predefined, and thus whose procedure is 
not that method. The subject method of an instance of 
this class is the method for operations "do", "either", 
"if", "loop", or "select". 
30 Note: Which of the above operations applies is 

determined by examining the identifier by means 
of whose execution the operation was requested. 
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4.2.7 Procedure Frame 

Attributes 

position 
procedure 

5 A "procedure frame" is a frame entailing a 

procedure ' s performance . 

A procedure frame's native attributes are the 
procedure being performed (attribute "procedure") and the 
procedure's current position (attribute "position"). A 
10 procedure's "current position" is that of the item the 
Engine is currently executing. 

Note : The procedure is either the "procedure" 

attribute of the subject method, the responder 
of the feature the method implements, or an 
15 argument of the feature. 

4.2.9 Repeat Frame 

Attributes 

repetitions 
r ene t i t ionsSoFar 
20 A "repeat frame" is a predefined frame whose subject 

method is the method for operations "repeat" and whose 
"procedure" attribute is that operation's responder. 

A repeat frame's native attributes are the number of 
performances of the frame's "procedure" attribute, 
25 including the current performance, that have been 

initiated (attribute "repetitionsSoFar") , and the number 
requested at the outset (attribute "repetitions") . 

4.2.9 Restrict Frame 

Attributes 
30 permit 

A "restrict frame" is a predefined frame whose 
subject method is the method for operations "restrict" and 
whose "procedure" attribute is that operation's argument. 
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A restrict frame's native attribute is the permit the 
subject held at the start of the Engine's performance of 
the subject method (attribute "permit"), 

4.2.10 Send Frame 
5 Attributes 

tickets 

A "send frame" is a go frame whose subject method is 
the predefined method for operations "send". 

A send frame's native attribute comprises one or more 
10 of the tickets originally in the operation's argument 
(attribute "tickets") . 

4 . 2 . 11 Use Frame 
Attributes 

resource 

15 A "use frame" is a predefined frame whose subject 

method is the method for operations. "use" and whose 
"procedure" attribute is one of the operation's arguments. 

A use frame's native attribute is the operation's 
responder (attribute "resource"). 

20 4.2.12 User-defined Frame 
Attributes 

responder 

stack 

varial?;U3 

25 A "user-defined frame" is a procedure frame whose 

procedure is that of the frame's subject method. The 
subject method is user-defined and is necessarily a value 
of an implementation's "instanceMethods" or "setMethods" 
attribute . 

3 0 A user-defined frame's native attributes are the 

method's responder (attribute "responder"), stack 
(attribute "stack"), and variables (attribute 
"variables"), the latter in the order of their identifiers 
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in the method's "variables" attribute. The responder is 
the agent of whose "frames" attribute the user-defined 
frame is an item. 

Note : Let "I", if any, be an item in the "procedure" 

5 attribute of the frame, "B", if any, below the 

user-defined frame in the agent's "frames" 
attribute. In particular, let n I" be the item 
whose position in the "procedure" attribute is 
the "position" attribute of n B" . "I" is either 

10 (a) non-existent: the subject method is for 

operations "live"; (b) an identifier preceded by 
a "setAt tribute" modifier: the subject method is 
a value in an implementation's "set Met hods" 
attribute; (c) an identifier not so preceded: 

15 the subject method is a value in an 

implementation's " instanceMethods " attribute; or 
(d) an "escalate" selector: the subject method 
is as described in either (b) or (c) above. 

4.2.13 While Frame 
20 Attributes 

isPrecondition 
precondition 

A "while frame" is a predefined frame whose subject 
method is the method for operations "while" and whose 

25 "procedure" attribute is that operation's responder. 

A while frame's native attributes reveal the executed 
object that is the operation's argument (attribute 
"precondition") and whether the argument, rather than the 
responder, is being performed (attribute 

30 "isPrecondition"). The while frame's "position" attribute 
pertains to whichever of the two procedures is being 
performed. 

4 . 3 Encoding Attributes 

The encoding attributes are defined below. 



413 



EP 0 634 719 A2 



4.3.1 Agent 

Native to this class are the following encoding 
attributes . 

frames : 

sealed Stack [Frame] I / 

The responder's pending frames. The bottom frame's 
subject method is a user-defined method for operations 
"live". The top frame's subject method is the built-in 
method for operations "go" or "send". There are zero or 
more other frames. 

nativePermit r 

sealed copied Permit | Nil; 

Either the responder's native permit, if it differs 
from the permit the responder holds, or a nil, otherwise. 

3-5 4.3.2 Catch FramP 

Native to this class is the following encoding 
attribute. 

exception; 
sealed Class; 

20 The class either class "Exception" or a subclass 

thereof that is performing the responder's subject 
method . 

4-3.3 Collection 

Native to this class is the following encoding 
25 attribute. 



items : 

sealed List [Object] I ; 
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The responder's items. The position of any 
particular item is undefined. 

4.3,4 Collection Stream 

Native to this class are the following encoding 
5 attributes. 

position : 

sealed Integer) Nil; 

Either the current position in the responded if the 
responder has produced neither none nor all of its items, 
10 or a nil, otherwise. 

source : 

sealed Collection [Obj ect] (Nil; 

Either the responder's source, if the responder has 
not produced all of its items, or a nil, otherwise. 

15 4.3.5 Dictionary 

Native to this class is the following encoding 
attribute . 

associations : 
sealed List [Object] ! ; 

The keys and values that form the responder's items. 
The items at positions 2i-l and 2i of the list are a key 
and its associated value, respectively. The position of 
any particular key-value pair is undefined. 

4.3.6 List 

Native to this class is the following encoding 
attribute . 
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items : 

sealed List [Object] ! ; 
The responder's items. 

4.3-7 Pattern 

5 Native to this class is the following encoding 

attribute, 

text : 

sealed copied String; 
The responder's text. 

*0 4-3.9 Procedur e Framp 

Native to this class are the following encoding 
attributes . 

position ; 
sealed Integer; 

5 The current position in the responder's "procedure" 

attribute. 

procedure ; 
sealed Procedure ; 

The procedure whose performance the responder 
3 entails. 



4 - 3 -9 Random Stream 

Native to this class is the following encoding 
attribute. 



seed : 

sealed Integer; 
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Either the responder's seed, if the responder has not 
produced an item, or the item the responder produced last, 
otherwise . 

4 .3 . 10 Repeat Frame 
5 ' Native to this class are the following encoding 
attributes . 

■repetitions : 
sealed Integer ; 

The number of performances of the responder's 
10 "procedure" attribute requested of the responder's subject 
method via the argument of operations "repeat". 

repetitionsSoFar ; 
sealed Integer; 

The number of performances of the responder's 
15 "procedure" attribute, including the current performance, 
initiated so far. 

4 .3 . 11 Restrict Frame 

Native to this class is the following encoding 
attribute. 

20 permit : 

sealed copied Permit ; 

The permit the subject held at the start of the 
performance of the responder's subject method. 



4 . 3 . 12 Send Frame 
25 Native to this class is the following encoding 

attribute . 
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10 



30 



35 



40 



45 



50 



tickets : 

sealed List [Ticket] ! ; 

One or more of the tickets in the list supplied as 
the argument of the responder's subject method. The 
5 position of any particular ticket is undefined. 



4.3.13 Stack 

Native to this class is the following encoding 
15 attribute. 

items : 

10 sealed Stack [Object] !; 

20 

The responder's items. 

25 4 .3 .14 Time 

Native to this class are the following encoding 
attributes . 



15 £iat: 

sealed Integer; 

The "dst" attribute of the calendar time that would 
have been produced, when and where the responder was 
produced, by requesting "new" of class "Time" and 
20 converting its result to a calendar time. 

second : 

sealed Integer ; 

The "second" attribute of the unnormalized calendar 
time that denotes the same absolute point in time, "T", as 
25 does the responder, but that would denote time "T 0 " if its 
"second" attribute alone were set to zero. 



55 
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Note : T 0 is the time relative to which all times are 

measured. It coincides with the start of a 
minute in the Gregorian calendar. This 
attribute, then, is the number of seconds that 
5 separate T from T 0 . The attribute is strictly- 

positive or negative if the time follows or 
precedes T 0 , respectively. 

zone : 

sealed Integer; 

0 The "zone" attribute of the calendar time that would 

have been produced, when and where the responder was 
produced, by requesting "new" of class "Time" and 
converting its result to a calendar time. 

4 . 3 . 15 Use Frame 
5 Native to this class is the following encoding 

attribute . 

resource : 
sealed Resource; 

The resource performing the responder' s subject 
0 method. 

4.3.16 User-defined Frame 

Native to this class are the following encoding 
attributes. 

responder: 
5 sealed Object; 

The responder of the responder' s subject method. 
stack : 
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sealed Stack [Object] ! ; 

The stack of the responder's subject method. 
variables : 

sealed List [Object] !; 
5 The variables of the responder's subject method. 

4 .3 . 17 While Frame 

Native to this class are the following encoding 
attributes . 

isPrecondition ■ 
10 sealed Boolean; 

Whether the responder's "precondition" attribute, 
rather than its "procedure" attribute, is being performed. 

precondition ; 
sealed Executed; 

15 The argument of operations "repeat". 

5. ENCODING PALLETTEfi 

Telescript's encoding palettes are defined in this 
section of the appendix. One section is devoted to 
language classes, another to encoding classes. All 

20 Engines of a network must agree on the following: (i) the 
method by which an assigned teleaddress' "provider" 
attribute is selected, and (ii) the method by which an 
assigned telename's "authority" attribute is selected. 
One embodiment of each of these methods is implemented in 

25 the computer software included as Microfiche Appendix G of 
this disclosure. 

5^_1 Conventions 
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A subsection is devoted below to each predefined 
flavor whose examples are encoded using a non-empty 
primary palette. First the language flavors and then the 
encoding flavors are considered in alphabetical order, 
5 One additional subsection, entitled Mix-in, is devoted to 
the one secondary palette. 

Most every palette is defined using a table whose 
columns are labeled, and whose rows define predefined 
attributes , as follows . 
10 • Either "M" , if the attribute is mandatory, 

or the number assigned to the attribute, if 
the attribute is optional. 

• Attribute . The attribute's identifier. 

• Sender . The attribute's type, defined using the 
15 notation of Section A. 2. 4 of Appendix A. 

If the type is "Boolean" and just one of 
its two instances is permitted, "true" or 
"false" appears in lieu of "Boolean". 

• Receiver. Either a dash ("-"), if a sending Engine 
2 0 shall not omit the attribute from an 

encoding, or the instance of the type that 
the receiving Engine shall supply if the 
sending Engine does omit the attribute, 
otherwise . 



25 5 ..2 Language Classes 

The encoding palettes for the language classes are 
defined below. 

Note: The absence from this section of certain 

language classes is explained as follows. An 
30 object's class and isProtected attributes 

figure in its encoding, but not as attributes. 
An object computes its size attribute. A place 
is immovable and thus not encoded. A process' 
class is not user-defined unless the process is 
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an agent or a place. A stream computes its 
"current", "isDone", and "next" attributes. 

5.2.1 Aaent 

An example of this class is encoded using the primary 
5 palette in Table B.3. 



10 



15 







TABLE B_3 


# 


Attribute 


Sender 


Receiver 


M 


name 


Telename 




M 


permit 


Permit 




M 


frames 


Stack [Frame] ! 




1 


brand 


Object 1 


Assigned 1 




privateClasses 


Set [Cited] 


Cleared 




nativePermit 


Permit 


Nil 




priority- 


Integer 


Permit 2 


• 


contacts 


Set [Contact] 


Absent 



•This attribute shall be supplied by either the sending 
Engine, if the agent is transferred within a domain, or 
the receiving Engine, otherwise. 

2 The "priority" attribute of the agent's "permit" 
20 attribute. 

5 - 2 - 2 Association 

An example of this class is encoded using the primary 
palette in Table B.4. 



TABLE B.4 


& | Attribute 


Sender 


Receiver 
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M 


"key" 


Object 




M 


"value " 


Object 





5.2.3 Attribute 

An example of this class is encoded using the primary 
5 palette in Table B.5. 



10 





TABLE B.5 


I 


Attribute 


Sender 


Receiver 


1 


" exceptions " 


Set [Identifier!] 1 


Cleared 


2 


"isPublic" 


true 


false 


3 


"constraint" 


Constraint 


See Constraint 


4 


"isSet " 


true 


false 



In a class, this is "Set [Class] - . Each class is class 
"Exception" or a subclass thereof. 



5-3-4 Calendar Time 

15 An example of this class is encoded using the primary 

palette in Table B.6. 



20 





TABLE 




Attribute 


Sender 


Receiver 


l 


"day" 


Integer 


Nil 


2 


"dayOfWeek" 


Integer 


Nil 


3 


"dayOfYear" 


Integer 


Nil 


4 


"dst " 


Integer 


Nil 


5 


"hour" 


Integer 


Nil { 
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5 





TABLE B.6 


6 


"minute" 


Integer 


Nil 


7 


"month" 


Integer 


Nil 


8 


"second" 


Integer 


Nil 


9 


"year" 


Integer 


Nil 


10 


"zone" 


Integer 


Nil 



5 - 2 -5 qitat^on 

An example of this class is encoded using the primary 
palette in Table B.7. 



10 



TABLE B_7 


jt 


Attribute 


Sender 


Receiver 


M 


"title" 


Identifier 1 




1 


"author" 


Telename 


Nil 


2 


" ma j orEdi tion " 


Integer 


Nil 


3 


"minorEdition" | Integer 


Nil 



15 5.2.6 Class 

An example of this class is encoded using the primary 
palette in Table B.8. 



20 



1 4 




TABLE B.a 






Attribute 


Sender 


Receiver 


M 


"citation" 


Citation 




M 


" interface n 


Interface 
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5 



TABLE B.8 


1 J "implementation" 


Implementation 


Nil 



5.2.7 Class Definition 

An example of this class is encoded using the primary 
palette in Table B.9. 



5 



10 



TABLE B.9 


4 


Attribute 


Sender 


Receiver- 


M 


" interface 


Interface 




M 


"title" 


Identifier! 




1 


" implementation" 


Implementation 


Nil 


2 


" ma j orEdi t ion " 


Integer 


1 


3 


■ minor Edi t ion " 


Integer 


1 



5-2.8 Collection 

An example of this class is encoded using the primary 
palette in Table B.10. 

35 



15 




TABLE B.10 1 




4 


Attribute 


Sender 


Receiver 1 




l 


"items" 


List [Object] ! 


Cleared | 



5 - 2 ' 9 Constra ined Dictionary 

An example of this class is encoded using the primary 
20 palette in Table B.ll. 



50 



55 
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10 





TABLE B.n 


1 


Attribute 


Sender 


Receiver 


M 


"constraint" 


Constraint 




M 


"associations " 


List (Object J 


EEEE 







15 5 $.?-10 Constrained L-i at- 

An example of this class is encoded using the primary 
palette in Table B.12. 



20 



25 



30 



10 





TABI^E p. 15 




Attribute 


Sender 


Receiver 


M 


"constraint 11 


Constraint 






"items" 


List [Object] 





5 -^- 3 ^ Constrai ned 

An example of this class is encoded using the primary 
palette in Table B.13. 



35 



40 



45 



15 













TABLE B.U ] 




Attribute 


Sender 


Receiver j 


M 




"constraint M 


Constraint 




M 


"items " 


List [Object] 





5 ^ 2 * 12 - Constraint- 

20 An example of this class is encoded using the primary 

palette in Table B.14. 



50 



TABLE n m 



55 
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5 



10 



£ 


Attribute 


Sender 


Receiver 


1 


"is Instance " 


true 


false 


2 


"isOptional" 


true 


false 


3 1 


"classld" 


Identifier! 


'Object 


3 1 


"of Class" 


Class 


Obj ect 


4 


"passage " 


Identifier! 


'byRef 



'in a class, the "classld" and "of Class" attributes are 
present implicitly and explicitly, respectively, the 
former being the "title" attribute of the latter' s 

10 "citation" attribute. In a class definition and 

elsewhere, the "classld" and "ofclass" attributes are 
present explicitly and implicitly, respectively, the 
latter being a nil. In either a class or class 
definition, the constraint is the "constraint" attribute 

15 of an attribute definition, the "result" attribute of an 
operation definition, or an item of the "arguments" 
attribute of an operation definition. In any of these 
cases, that feature definition is a value in the 
"classFeatures" or "instanceFeatures" attribute of an 

20 interface. Finally, that interface is the "interface" 
attribute of the class or class definition. 



5.2.13 Contact 

An example of this class is encoded using the primary 
palette in Table B.15. 





TABLE B.15 


4 


Attribute 


?e^der 


Receiver 


1 


"subject n 


Process 


Nil 


2 


" sub j ectClass " 


Citation 


Nil 
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TABLE 


3 


"subjectName" 


Telename 


Nil 


4 


" sub j ectNotes " 


Object 


Nil 



5 ■ 2 , 14 Dictionary 

An example of this class is encoded using the primary 
5 palette in Table B.16. 





TABLE B.16 




Attribute 


Sender 


Receiver 




M 


"associations" 


List [Object] I 





5 . 2 . 15 Implementation 

An example of this class is encoded using the primary 
palette in Table B.17. 



20 







TABLE 




it 


Attribute 


Sender 


Receiver 


i 


" classMethods " 


Lexicon [Method] 


Cleared 


2 


" fromMethods" 


Lexicon [Method] 1 


Cleared 


3 


" instanceMethods n 


Lexicon [Method] 


Cleared 


4 


"properties " 


List [Identifier!] 


Cleared 


5 


"setMethods" 


Lexicon [Method] 


Cleared 


6 


"superclasses" 


List [Identifier! ] 2 


Nil 




"toMethods" 


Lexicon [Method] 1 


Cleared 




"vocabulary" 


Lexicon [Citation] 


Nil 



, this is "Dictionary [Class, Method]" 
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2 In a class, this is " List [Class] " . 



10 



5.2.16 Interface 

An example of this class is encoded using the primary 
palette in Table B.18. 



15 



20 



25 



10 





TABLE B.18 


£ 


Attribute 


Sender 


Receiver 


i 


" class Features " 


Lexicon [Feature] 


Cleared 


2 


n instanceFeatures " 


Lexicon [Feature] 


Cleared 


3 


"isAbs tract" 


true 


false 


4 


"sealedClassFeatures" 


Set [Identifier ! ] 


Cleared 


5 


" sealedlnstanceFeatures n 


Set [Identifier ! ] 


Cleared 


6 


"superclasses " 


List [Identifier! ] 1 


'Object 


7 


"vocabulary* 


Lexicon [Citation] 


Cleared 



30 



35 



40 



'The receiver supplies a list of one identifier, that of 
15 class "Object". In a class, this is "List [Class] • , and 
the receiver supplies a list of one class, class "Object". 

5.2.17 Lexicon 

An example of this class is encoded using the primary 
palette with which an example of class "Dictionary" is 
20 encoded. 

Note: The "constraint" attribute of a lexicon is fixed 

by the Instruction Set. 



45 



5.2.18 List 

An example of this class is encoded using the primary 
25 palette in Table B.19. 



50 



TABLE B.19 



55 
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4 


Attribute 


Sender 


Receiver 


M 


" items " 


List [Object] ! 





5.2.19 Method 

An example of this class is encoded using the primary 
5 palette in Table B.20. 





TABLE B.20 


* 


Attribute 


Sender 


Receiver 


1 


"procedure " 


Procedure 


Cleared 


2 


"variables M 


List [Identifier!] 


Cleared 



10 5. 2. 2Q Mix-in 



The secondary palette is that in Table B.21. 







TABJ,E B.Jl, 


1 


Attribute 


Sender 


Receiver 


1 


"citation" 


Citation 


Absent 


2 


"constraint" 


Constraint 


Absent 


3 


name 


Telenarae 


Absent 





Note: A hashed object's "hash" attribute and an 

interchanged object's "digest" attribute are 
computed by the object. 

20 5.2.21 Operation 

An example of this class is encoded using the primary 
palette in Table B.22. 
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5 



10 





TABLE B.22 




i 


Attribute 


Sender 


Receiver 


i 


exceptions 


Set [Identifier!] 1 


Cleared 


2 


isPublic 


true 


false 


3 


arouments 


List [Constraint] 


Nil 


4 


result 


Constraint 


Nil 



J In a class, this is "Set [Class] " . Each class is Exception 
20 or a subclass of it. 



5-2.22 Package 

10 An example of this class is encoded using the primary 

25 palette in Table B.23. 



15 





TABLE p r 23 


& 


Attribute 


Sender 


Receiver 


M 


"citation" 


Citation- 




M 


"items" 


List [Class] - 





Note: The "constraint" attribute of a package is fixed 

by the Instructor Set . 

40 

5-2.23 Pattern 

An example of this class is encoded using the primary 
20 palette in Table B.24. 



45 






TABLE B.24 








1 


Attribute 


Sender 


Receiver 


50 


M 


"text" 


String 





55 



431 



BNSOOCID: <EP 063471 9A2 J ^> 



EP 0 634 719 A2 



10 



5 .2 .24 Permit 

An example of this class is encoded using the primary 
palette in the table. 



15 



20 



25 



30 



10 







TABLE B.25 j 




Attribute 


Sender 


Receiver 




allowance 


Integer 


Of subject 1 




canCharge 


true 


false 


3 


canGo 


true 


false 


4 


canProcreate 


true 


false 


5 


canRestart 


true 


false 




6 


canSend 


true 


false 


7 


canTertninate 


true 


false 


8 


deadline 


Time 


Of subject 


9 


priority 


Integer 


Of subject 



35 



15 5.2.25 



40 



45 



50 



Petition 



An example of this class is encoded using the primary 
palette in the table. 



20 







TABLE 


B.26 




£ 


Attrifcmf^ 


Sender 


Receiver- 


l 


"agent Class" 


Citation 


Nil 


2 


"agentName" 


Telename 


Nil 


3 


n maximumWai t M 


Integer 


Nil 
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5 5.2.26 Random Stream 

An example of this class is encoded using the primary 
palette in Table B.27. 



10 


TABLE B.27 


5 


1 


Attribute 


Sender 


Receiver 












M 


"seed" 


Integer 





15 



20 



25 



30 



35 



5 .2 .27 Resource 

An example of this class is encoded using the primary 
palette in Table B.28. 



10 





table; p. ?e | 


* 


Attribute 


Sender 


Receiver j 










1 


"condition" 


Identifier I 


Undefined 1 


2 


" conditions " 


Set [Identifier!] 


Undefined 1 



l The "conditions" attribute comprises one identifier which 
15 equals the "condition" attribute. This identifier is 
undefined . 

Note: Any processes other than the subject awaiting 

use of the resource when the subject began its 
trip await the resource no longer, having been 
20 left behind. 



40 



45 



5.2.2Q Set 

An example of this class is encoded using the primary 
palette with which an example of class "Collection" is 
encoded . 



25 5,2,29 



Stack 



An example of this class is encoded using the primary 
palette in Table B.29. 



50 
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1 




TABLE B.2 9 




Attribute 


Sender 


Receiver 


M 


"items" 


Stack [Object] ! 





5-2.30 Teleaddregfl 

An example of this class is encoded using the 
palette in Table B.30. 



10 





TABLE B.30 


1 


Attribute 


Sender 


Receiver- 


M 


"provider" 


OctetString 




1 


" location" 


String 


Nil 


2 


rt rout i ngAdvi ce " 


List [OctetString] 


Cleared 



5.2.31 Telename 



An example of this class is encoded using the primary 
palette in Table B.31. 



15 





TABLE 1 


& 


Attribute 


Sender 


Receiver 


M 


"authority" 


OctetString 




1 


"identity" 


OctetString 


Nil' j 



5-2.32 Telenumber 

20 An example of this class is encoded using the primary 

palette in Table B.32. 



TABLE B.32 
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5 



& 


Attribute 


Sender 


Receiver 


M 


" country " 


DialString 




M 


"telephone" 


DialString 




1 


"extension" 


DialString 


Nil 



15 

5 5.2.33 Ticket 

An example of this class is encoded using the primary 

palette in Table B.33. 



L 


TABLE B.33 




Attribute 


Sender 


Receiver 


i 


"travelNotes" 


Object 


Nil 


2 


"way" 


Way 


Nil 


3 


"desiredWait" 


Integer 


Nil 


4 


"destinationAddress" 


Teleaddress 


Nil 


5 


11 destinationClass " 


Citation 


Nil 


6 


" des t inat ionName " 


Telename 


Nil 


7 


"destinat ionPermit n 


Permit 


Nil 


8 


" max imumWa it" 


Integer 


Nil 



40 

5.2.34 Ticket Stub 

An example of this class is encoded using the primary 
20 palette in Table B.34. 



45 



50 



TABLE B.34 




Attribute 


Sender 


Receiver 


1 


"travelNotes" 


Object 


Nil 
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15 



TABLE B.34 


2 


J "way" 


| Way 


Nil 


5.2.35 


Time 






An example of this class is encoded using the primary 
palette in Table B.35. 




TABLE B.35 


t 


Attribute 


Sender, 


Receiver 




"dst" 


Integer 


0 




"second" 


Integer 


0 


• 


n zone " 


Integer 


0 


5.2.36 


TriD Exception 






An 

palette 


example of this class is encoded using 
in Table B.36. 


the primary 


1 


TABLE 




Attribute 


Sender 


Receiver 




"ticketStub" 


TicketStub 


Nil 


5 . 2 . 37 


Unexpected Exception 





An example of this class is encoded using the 
palette in Table B.37. 







TABLE B.37 I 


20 


* 


Attribute 


Sender 


Receiver 




M 


"exception" 


Exception 


■ 
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5.2.38 Way 



An example of this class is encoded using the primary- 
palette in Table B.38. 



TABLE B.38 


1 


Attribute 


Sender 


Receiver 








1 


" authenticator " 


Authenticator 


Nil 


2 


"means" 


Means 


Nil 


3 


" name " 


Telename 


Nil 



20 



5 - 3 Encoding Classes 
10 The encoding palettes for the encoding classes are 

defined below. 



25 



30 



35 



40 



45 



5-3.1 Catch Frame 

An example of this class is encoded using the primary 
palette in Table B.39. 



15 







TABIrf? p,3? 




1 


Attribute 


Sender 


Receiver 


M 


"position" 


Integer 




M 


" procedure n 


Procedure 




M 


"exception" 


Class 





20 5.3.2 Collection Stream 

An example of this class is encoded using the primary 
palette in Table B.40. 



TABLE B.4Q 



50 
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5 



10 



jl 


Attribute 


Sender 


Receiver [ 


1 


"position" 


Integer 


Nil 1 


I 2 


" source " 


Collection [Object] 


Nil 

— !l 


5.3.3 


Predefined |?ramp 






An 

palette 


example of this class is encoded using 
in Table B.41. 


the primary 






TABLE B.41, 




& 


Attribute 


Sender 


Receiver 


M 


"position" 


Integer 




M 


"procedure" 


Procedure 




5,3,4 


Repeat Pramp 







example of this class is encoded using the primary 



palette in Table B.42. 



15 





TABLE B.42 




Attribute 


Sender 


Receiver 




"position" 


Integer 




M 


"procedure" 


Procedure 




1 


" r epe t i t i onsSoFar " 


Integer 


1' 


2 


"repetitions" 


Integer 


1 



20 5.3-5 Restrict P^m^ 

An example of this class is encoded using the primary 
palette in Table B.43. 
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10 



15 







TABLE 






Attribute 


Sender 


Receiver 


M 


"position" 


Integer 




M 


"procedure" 


Procedure 




M 


"permit" 


Permit 





20 



5.3.6 Send Fram^ 

An example of this class i s encoded using the primary 
palette in Table B.44. 





- 




TABLE 




25 10 




Attribute 


Sender 


Receiver 




M 


"tickets" 


List [Ticket] ! 





30 



35 15 



40 



45 



50 



5 • 3 - 7 - Use FraTr^ 

An example of this class is encoded using the primary 
palette in Table B.45. 







TABLE 




i 


Attribute 


Sender 


Receiver- 


M 


"position" 


Integer 




M 


"procedure " 


Procedure 




M 


11 resource " 


Resource 





20 S^B D 3 er-d>.fin e d F^m~ 

An example of this class is encoded using the primary 
palette in Table B.46. 



TABLE B,^ 



n 
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5 



& 


Attribute 


Sender 


Receive 1 


M 


"position 11 


Integer 




1 


"responder" 


Object 


Agent 1 


2 


"stack" 


Stack [Object] I 


Cleared j 


3 


"variables" 


List [Object] ! 


Cleared 



'The agent of whose frames attribute this frame is an item. 

5 - 3 -3 While Frame 

An example of this class is encoded using the primary 
palette in Table B.47. 



5 







TABLE p. 47 


1 


Attribute 


SSJKier 


Receiver- 


M 


"position" 


Integer 




M 


"procedure " 


Procedure 




M 


" pr econdi t ion " 


Executed 




1 


" isPrecondition" 


true 


false 
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APPENDIX C 

Copyright ® General Magic, Inc. 1992 f 1993. All Rights 
Reserved 

The following table of contents is to assist the 
5 reader in understanding the organization of and locating 
information within this appendix. 

Table of Contents 
1 . INTRODUCTION 
Overview 
10 Organization 
References 





2. 


INTERFACE CONCEPTS 




2.1 


Telename 




2.2 


Network 


15 


2.3 


Engine 




2.4 


Platform 




2.5 


Region 




2.6 


Outpost 




2 . 7 


Domain 


20 


2.8 


Transfer 




2 . 9 


Transfer Unit 




2.10 


Destination 




2.11 


Transfer Group 




2 . 12 


Way 


25 


2.13 


Means 




2.14 


Reservation 




2.15 


Rank 




3 . 


COMMUNICATION CLASSES 




3 . 1 


Reservation 


30 


3.2 


Reservable Means 




3.3 


PSTN Means 



3 * 4 Existing Connection Means 

4 - INTERFACE IN TELESCRIPT 
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4.1 


Engine 




4 .2 


Platform 




4 . 3 


Destination 




4 .4 


Failure 


5 


> 5 . 


ROUTING 






Routing Algorithm 




6 . 


INTERFACE IN C++ 






Interface description 






Tasks 


10 




CI Class 




7 . 


TELESCRIPT INTERFACE OBJECTS 




7.1 


Interface Conventions 




7.2 


TsCharacter 




7.3 


TsDestination 


15 


7.4 


TsDestinationList 




7.5 


TsExi s t ingConne c t i onMeans 




7.6 


Ts Integer 




7.7 


TsIntegerList 




7.8 


TsMeans 


20 


7.9 


TsObj Specifier 




7.10 


TsOctet 




7. 11 


TsOctets 




7. 12 


TsPSTNMeans 




7.13 


Ts Re s e rvab 1 eMe ans 


25 


7. 14 


TsRe s e rvat i on 




7. 15 


TsString 




7. 16 


TsTeleaddress 




7. 17 


TsTelename 




7.18 


TsTelenumber 


30 


7. 19 


TsWay 



1 - INTRODUCTION 



Overview 

This appendix defines the "communication services 
that a Telescript engine can obtain from the platform 
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which it runs. Two engines employ these services to 
transfer the representation of an "agent" from a place in 
one engine to a place in the other, as required by 
Telescript's "go" and "send" operations. 
5 This appendix has two main parts. First, this 

appendix describes the communication services that a 
Telescript engine requires in an abstract way, using 
Teiescript to describe the interface between engine and 
platform. Second, this appendix documents a C++ 
10 "application programming interface" (API) which provides 
those services. 

Organization 

This appendix is divided into seven sections. 
Section 1 is this introduction. Section 2 describes the 

15 basic concepts of the interface. Section 3 describes some 
additional Telescript classes. Section 4 specifies the 
interface in Telescript . Section 5 describes a transfer 
in more detail. Section 6 describes a C++ API which 
implements the interface. Section 7 describes C++ 

20 representations of Telescript classes which are used in 
the API. 

References 

This appendix relies upon Appendix A of this 
disclosure . 

25 INTERFACE CONCEPTS 

This section of this appendix describes the basic 
concepts of Telescript communication and communication 
interfaces. Many of the objects described here have 
direct representations in the Telescript instruction set 

30 or in the communication interface of the engine. 

2 . 1 Telename 
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Telescript supports the movement of objects between 
places and specifically between engines. Every place in 
the Telescript universe is assigned a distinct "telename" . 
Telenames have two attributes, an "authority" and an 
5 "identity". 

Telescript supports telenames, whether assigned or 
otherwise. An "assigned telename", associated with an 
object by a Telescript engine, always contains both an 
authority and an identity. A telename which is not 
10 "assigned" purports to identify one or more Telescript 
objects. A telename which is not "assigned" can have its 
identity attribute omitted, in which case the telename can 
actually identify several objects. 



15 



2 .2 Network 

A Telescript "network" comprises one or more regions. 
The network may not fully interconnect all of its regions 
and "point-to-point" transfer of information may not be 
possible between any two of them. Regions are 
interconnected, however, to the extent that the network 
20 can provide "store* and- forward" transfer of information 
between any two of them. 

2 . 3 Engine 

An "engine" is a computer process that implements the 
abstractions of the Telescript instruction set. An engine 
25 does this, in part, by communicating with other engines. 
An engine is denoted by an assigned telename. 

2.4 Platform 

A "platform" is a collection of hardware and software 
that supports one or more engines. A platform enables 
30 engines to communicate with other engines on the same 
platform and on other platforms to which the platform is 
connected. 



EP 0 634 719 A2 



2 . 5 Region 

A "region" comprises the engines and supporting 
platforms operated by an individual or organization. 

A region fully interconnects the platforms the region 
5 contains. Thus the region enables the point-to-point 
transfer of information between any two of these 
platforms. Each region contains one or more platforms 
that provide access to and egress from the region. It is 
by means of these platforms that regions are 
10 interconnected to form a network. A region is denoted by 
a telename in which the identity attribute is omitted. 

2.6 Outpost 

A region can have an outpost in another region. An 
"outpost" is a place in a region which routes traffic from 
15 that region to the outpost's region. 

2 . 7 Domain 

A "domain" is a region, together with all of its 
outposts in other regions. 

2 . 8 Transfer 

20 A "transfer" is the conveyance of a transfer unit 

from one engine, the "source engine", to another, the 

"destination engine". 

A transfer unit specifies a "destination" which can 

be used to route the transfer. Additionally, a way can be 
25 provided which can influence the route and "transport" 

used for the transfer. 

2 . 9 Transfer Unit 

A "transfer unit" is conveyed between engines in a 
transfer. A transfer unit consists of an octet string, 
30 and a destination. These are the only data items that are 
delivered end to end between engines. Additional data is 
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involved in specifying the transfer to the "originating 
platform" and in receiving a transfer at the destination. 

■3 tIQ Destination 

A -destination- describes the ultimate destination of 
5 a transfer unit. 

2 - 11 Transfer Group 

The Telescript -send" operation, which is described 
in Appendix A, can result in the same octet string being 
delivered to several destinations. A "transfer group" is 
10 a collection of transfer units and their associated 

destinations, together with one copy of the octet string 
being conveyed. 

A transfer group logically represents its component 
transfer units. A platform can break up a single transfer 
15 group into multiple smaller transfer groups and/or single 
transfer units. 

2.12 Way 

A -way" specifies a region or engine, a means of 
communicating with the region or engine, and 
20 -authentication information" used to do so. 

A transfer out of an engine can specify a way, i.e, 
the -way out", which defines communication requirements 
for the transfer. incoming transfers provide engines with 
a way, i.e., the -way back", which can be used as the way 
25 out in subsequent transfers towards the original source. 

2 . 13 Means 

A "means" specifies a type of transport to be used 
for a transfer, e.g., wireline or wireless network a 
means contains transport specific data such as a ..quality 
30 of service- parameter or the telephone number for a " PSTN" 
connection. 
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A "reservable means" specifies a type of transport 
for which a reservation is honored. 

2 . 14 Reservation 

A "reservation" is a request that a connection 
5 established by a platform as the result of a transfer be 
maintained for some period of time. Reservations are 
hints to allow a connection to be used for multiple 
transfers . 

A reservation has meaning only when a transfer 
10 specifies a way with a reservable means. 

2 . 15 Rank 

Some transfers may be considered "privileged" . A 
"rank" is an indication of privilege. It is an integer, 
the value zero meaning unprivileged. The meaning of non- 
15 zero values is source region specific. In inter-region 
transfers, a rank can be regarded as a hint which can be 
changed or ignored. 

Communication Classps 

This section defines additional Telescript classes 
20 which are not present in Appendix A of this disclosure. 



l^X Reservation 
Object 
40 • Reservation 



Class 

25 Reservation : 

interface () = (...); 



Public Instance Attributes 
50 id: 

Integer; 
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An identifier for a reservation created by a 
platform. 

3 .2 Reservable Means 
Ob j ect 
5 • Means 

• • Reservable Meana 

Class 

ReservableMeans : 

abstract interface (Means) = (...); 

10 Public Instance Attributing 
reservation ; 
Reservation; 

An identifier for a reservation created by a 
platform. 

15 3.3 PSTN Means 
Object 

• Means 

• • Reservable Means 

• • • PSTN Mcgim 

20 Class 

PSTNMeans ; 

interface (ReservableMeans) = (...); 

Public Inst ance Attributes 
t e 1 eohoneNumbe r : 
25 Telenumber; 

The telephone number to be used for this trip. 
^1 Existing Connection Mpahc 
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Ob j ect 

Means 

• • Reservable Means 

• • • Existing Connection Means 

5 Class 

ExietinaConnectionMeans : 

interface (ReservableMeans) = {...); 

Public Instance Attributes 
connect ionID : 
10 Octets; 



A identifier which a platform can use to identify a 
connection. 

25 INTERFACE IN TELE SCRIPT 

In this section, the interface between an engine and 
15 its platform is specified as if both were Telescript 
objects, which they are not. It is intended that this 
definition be considered generic, i.e. independent of 
specific programming languages used to implement engines 
and platforms. 

The following Telescript class definitions are used 
in this interface. See Appendix A and Section 3 of this 
Appendix for their definitions: 



20 



Integer 
List 

25 Octetgtripq 
Telename 
Teleaddress 
Way 

Reservation 
30 4 . 1 Engine 
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Ob j ect 

• Engine 

Class 

Engine : 

5 interface ( ) ^ (...); 

Public Instance Operations 
transferln: 
op ( 

octets : OctetString; 
10 destinations; List [Destination] ; 

ranJc : Integer ; 
way: Way; 

timeAdjust : Integer) 
throws TransferlnFailed 

15 Delivers one or more transfer units associated with a 

single transfer group to the engine. The transfer units 
are represented by the octets, destinations and rank. The 
way back (argument "way") contains the telename of the 
engine which performed operation "transf erOut " , The way 
20 back can provide an existing connection means which can be 
used to make a return trip. 

Argument "timeAdjust" is the number of seconds by 
which the clock of the source platform trails the clock of 
the destination platform. The responder can use this 
25 information to adjust certain times that were generated 
relative to the source engine's clock. 

The "TransferlnFailed" exception is thrown if the 
engine is unable to receive the transfer units. 

transf erFailftrf r 
30 op ( 

failure: Failure ; 
octets : OctetString; 
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destinations: List [Destination]; 
rank: Integer; 
way: Way; 

timeAdjust : Integer) 
5 throws TransferFailedFailed; 

Delivers one or more failed transfer units associated 
with a single transfer group to the engine. The 
parameters for this operation are identical to those of 
operation n transf erln" with the addition of the reason for 
10 the failure (argument "failure") . 

It is possible that a " transf erFai led" operation can 
happen before a " transf erOut Complete" has been received at 
the source engine for the transfer group. 

If failure is "invalidMeans" , the responder will be 
15 the source engine if possible. 

An exception is thrown if the responder is unable to 
receive the failed transfer units 
("TransferFailedFailed") . 



transf erOutFailed • 
20 op ( 

reason: Failure; 
35 groupID: Integer ; 

failures: List [Integer] | Nil) 
throws UnknownTransferGroup , UnknownTransf erUnit ; 



25 One or more transfer units in the transfer group 

(argument "groupID") has failed. The cause of the failure 
is given in argument "reason" . The particular units that 
have failed are identified by a list (argument "failures") 
of integer indices into the original list of destinations 

30 given at performance of operation transf erOut. List 

indices begin at one, which identifies the first unit in 
the transfer group. 
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If a list is not provided, i.e, if the value of 
argument "failures" , is nil, every transfer in the group 
has failed. This is identical to a list which enumerates 
all the units in the original group. 
5 An exception is thrown if the responder did not 

previously perform a transf erOut operation denoted by 
argument "groupID" { ''UnknownTransf er Group" ) , or one of the 
items of argument "failures" i s not a valid index into the 
destination list for this transfer group 
10 ("UnknownTransf erUnit") . 

tranaferQ utComplebP ? 

op (groupID: Integer; ser ial Number : Integer) 
throws UnknownTransf erGroup; 

indicates that the "transf erOut - operation associated 
15 with a particular transfer group (argument "groupID") has 
been completed. m particular there can be no further 
» transf erOutFailed" operations for this group. Any 
resources associated with the transfer units in this group 
may be released. 

20 An exception is thrown if the responder did not 

previously perform a transferOut operation denoted by 
argument "groupID" ( "UnknownTransf erGroup" ) . 



Platform 
Object 
25 • Platform 

Class 

Platform: 

interface () *= (...); 

Construci-inn 
30 initial i rr~ . 

op (engine: Telename) ; 
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Initializes the responder for use by the named engine 
(argument "engine") . 

Public Insta nce Operations 
transf erOut : 
5 op (octets: OctetString; 

destinations: List [Destination]; 
rank : Integer ; 
way : Way | Nil ; 
desiredDuration : Integer; 
.0 maximumDuration : Integer; 

groupID: Integer) 
throws InvalidDestination, InvalidWay; 

Requests delivery of a transfer group, which is 
defined by arguments "octets", "destinations" , and "rank", 

.5 to one or more destination engines. The group is 

identified by the group id (argument "groupID") . This 
operation results in one of operations "transf erln" , 
" transf erOutFailed" or "transf erFailed" subsequently 
referencing each of the transfer units that make up this 

0 group . 

The rank (argument "rank") specifies whether this 
transfer is privileged. 

If argument "way" is non-not a nil, it will be used 
to route the transfer. 

5 The desired duration of the transfer is specified in 

seconds (argument "desiredDuration"). This is the maximum 
elapsed time desired for the transfer. A value of zero 
for the desired duration indicates that no desired 
duration is associated with this transfer. 

0 The maximum allowed duration for the transfer is 

specified in seconds {argument "maximumDuration") . This 
is the maximum time allowed for the transfer. If 
operation "transf erOutComplete" has not happened this many 
seconds after the " transf erOut" operation, then the effect 
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is the same as though a " f ailTransf er " operation is 
performed for this group. A value of zero for the maximum 
duration indicates that no maximum duration is associated 
with this transfer. 
5 An exception is thrown if the destination list is 

invalid ( " invalidDestination" ) or if argument "way" is 
supplied but has no non-nil attributes ( " invalidWay" ) . 

f ailTransf er : 
op (groupID: Integer) 
1 0 throws UnknownTrans f erGroup ; 

Requests that all pending transfer units in the 
transfer group identified by the group id (argument 
"groupID") be failed. 

It is possible that not all transfer units in a 
15 transfer group can be failed. Transfer units failed as a 
result of this operation will cause one or more 
" transf erOutFailed" operations followed by a 
"transf erComplete" . 

An exception is thrown if the group id was not used 
20 in a previous "transf erOut " (operation 
" UnknownTrans f erGroup" ) . 

makeReservat ion : 

op (duration: Integer) Reservation 
throws CannotReserve ; 

25 Returns a new reservation of duration (argument 

"duration") seconds. The reservation becomes active when 
the reservation is used in a reservable means for a 
subsequent » transf erOut " operation . 

Once a reservation expires, the reservation is no 

30 longer valid and transfers will fail if they attempt to 
use the reservation. 
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Reservations should be canceled with the 
"resetReservation" operation when they are no longer 
required. Platforms can impose maximum lifetimes on 
unused reservations. 
5 The "Cannot Re serve" exception is thrown if the 

responder is unable to provide a reservation. 

resetReservation : 

op (reservation: Reservation, duration: Integer) 
throws UnknownReservation, InvalidReservation; 



10 The duration of an existing reservation (argument 

20 "reservation") is changed to duration seconds. If the 

reservation is active when this operation is invoked, the 
effect is the same as if a "transfer Out n operation had 
just been done with a reservation of the new duration. 
15 Setting the duration to zero cancels a reservation. 

A canceled reservation is no longer valid. 

An exception is thrown if reservation was not 
obtained with a prior "makeReservation" operation 
CunknownReservation"), or if the reservation is no longer 
20 valid ("invalidReservation"). 



4.3 Destination 
Object 

• De s t i nat ion 



40 Class 

25 Destination : 

interface ( ) = (...),- 

45 Construction 

initialize : 
op ( 

3 0 name: Telename j Nil; 

so 

address: Teleaddress j Nil; 
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data: OctetString j Nil) ; 

Sets the responder's native attributes to the like- 
named arguments (arguments "name", "address", and "data") 

If all the attributes of a destination are nils, the 
5 destination is invalid. 

Private Instance Attributes 
address : 

Teleaddress j Nil; 
20 The address of the destination. 

10 data : 

OctetString | Nil; 
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Engine specific data associated with a transfer unit, 
name : 

Telename | Nil; 
15 The name of the destination. 

4 . 4 Failure 
Object 

• Failure 

Class 
20 Failure : 

interface { ) = {...); 

Private Instance Att ribute 
reason : 
Integer; 
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The reason for the failure of a transfer. The reason 
5 is represented as an integer enumeration shown in table 

C.l. 



TABLE C.l 

10 



15 


c 


1 


invalidDestination 


An invalid destination was 
provided . 






z 


i nva 1 i dWay 


An invalid way was 
provided. 


20 






inval idMeans 


An invalid means was 
provided . 


25 




A 
*± 


invalidReservation 


An invalid reservation was 
provided. 






5 


noDestinatione 


No destinations were 
specified. 


30 


10 


6 


maximumDurationExceeded 


The maximum duration has 
passed. 






7 


t r ans f e r s Fa i 1 ed 


failTransf ers was called. 


35 




8 


noLocalResources 


The platform failed to get 
some resource . 


40 




9 


des t inat ionUnreachable 


A transfer unit was 
undeliverable . 




10 


transferlnFailed 


transferln failed at the 
remote engine . 


45 


15 


11 


securityViolation 


There was an authentication 
failure . 








poesibleDuplicate 


May have been delivered. J 
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A platform can provide additional failure types. 

5 . ROUTING 

The "transferOut" operation of a transfer unit 
typically results in the "transferln" operation of the 
5 same unit at a different engine. If the transfer fails at 
the source platform, the transfer unit is failed with a 
"transferOutFailed" operation at the source engine. If 
the transfer unit is successfully transferred from the 
source platform but does not participate in a successful 

10 "transferln" op n « operation at the destination engine, it 
is failed to an engine with "transf erFailed" op n . 

The "transferOut" op° of a transfer group is logically 
equivalent to NT "transferOut" op n s of the component 
transfer units. The value of rank, desired and maximum 

15 durations and the way are identical for all the transfers. 
The list of destinations can imply op 11 "transferln" occurs 
at more than one destination engine. 

Typically, a platform will examine the list of 
destinations in a group and attempt to deliver the units 

2 0 with the minimum number of "transferln" op a s at destination 
engines. This implies that transfer units destined for 
the same engine will be transported and delivered as a 
group . 

Routing Algorithm 

2 5 If a way is provided in a performance of 

"transferOut" op n , the platform uses it to route the 
transfer. If a way is not provided, the platform must 
determine the destination engine. The steps for 
determining the destination engine based on the name and 

3 0 address associated with a transfer unit are: 

<start> 
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if the name is present but the address is not 

<use the name> 
if the address is present but the name is not 
if the provider is the current region 
5 find the corresponding name or <fail> 

set the name attribute of destination to 

name 

<start> 

else 

0 <use the address > 



if both the name and address are present 

If the provider is the current region 
<use the name> 

else 

5 <use the address> 



<use the name>: 

if, the authority is the current region 
if the identity is present 

determine the destination engine 
0 from the identity or <fail> 

determine the destination engine 
from the location or <fail> 

else 

5 route to the engine that contains the 

outpost of authority or <fail> 

<use the address>: 

if the provider is known 

route to the engine containing 
0 the outpost of the provider 

else 

fan each of the providers in the routing advice 
if it is the current region 
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remove it from the routing advice 

else 

if the provider is known 

route to the engine containing 
5 the outpost of provider 

if there is still no route then <fail> 

<f ail> : 

if the provider is the current region 
fail the transfer 

10 else 

if there is a default engine 
route to it 

else 

fail the transfer 

15 1L, INTERFACE IN C++ 

This section describes a C++ implementation of the 
engine -platform interface. This interface is derived from 
the Telescript specification of the interface in Section 



4. 



20 



25 



By necessity, the interface presented here reflects 
aspects of the current Telescript engine's implementation. 
In particular the C++ API includes operations on the 
engine which do not appear in the generic interface. 

Interface description 

The engine object is represented by the C++ class 
"CI". Operations on the engine object are provided as 
member functions of CI . 

The platform object is represented by a subclass of 
CI. The provider of a platform subclasses of CI and 
3 0 implements virtual functions of CI which represent the 
platform operations. 

The Telescript objects which appear as parameters to 
the operations on both engine and platform are represented 
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by a number of C++ classes which implement limited 
representations of Telescript objects. For example there, 
is a "Tslnteger" class which represents a Telescript 
"Integer" wherever "Tslnteger" appears in the API. A 
5 complete description of these Telescript Interface Objects 
appears in the next section of this appendix. 

Exceptions, which are specified in the Telescript 
representation of the interface, are implemented in the 
API as an enumerated type which is returned from all 
10 operations on both engine and platform. 

The storage for the data elements passed between 
engine and platform is owned by the caller of an 
operation. The storage can be reclaimed when an operation 
is complete. The only exception to this is the 
15 "transferOut" operation. The engine does not reclaim the 
elements of a transfer out until the corresponding 
"transferOutComplete" operation has been performed. 



Tasks 

The engine is implemented as multiple co-operating 
20 tasks running as separate threads with a non-preemptive 
scheduler. An instance of the CI class is run as a thread 
in the engine. A subclass of the CI class provides a 
function, »main{) which is called once and should only 
return when additional operations on the platform are no 
25 longer supported. 

"mainO- is expected to yield to the engine scheduler 
when there are no pending transferln" operations. 
"mainO" does this by calling "waitO". "waitO" takes 
an argument which is the number of milliseconds that the 
3 0 CI is willing to yield for. Typically the engine will not 
reschedule the CI's task until at least that amount of 
time has passed. An argument of zero to "waitO" implies 
that the CI is yielding but would like to be rescheduled 
as soon as possible by the engine scheduler. 
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An argument of -1 to "waitO" has the meaning that 
the CI wishes to block indefinitely. in this case, the CI 
is expected to call "satisfy ()" on the engine when the CI 
wishes to be rescheduled. "satisfy <) will cause a thread 
5 blocked in wait to resume execution as soon as the engine 
schedules the thread. This latter scheme would be 
appropriate for a CI implementation which was delivered an 
asynchronous event when there were new communications 
requests . 

10 On some operating systems, a CI implementation may 

wish to yield to the engine scheduler and be rescheduled 
when a file descriptor becomes ready. The "waitfd" 
operation specifies a file descriptor to wait on and may 
be used in conjunction with "wait () « to select on multiple 
15 file descriptors with a timeout. 

Performances of op n "transf erOut ■ are executed in the 
thread of the calling Telescript processes and not in the 
thread of the CI task. 

Operations on both engine and platform must execute 
20 relatively quickly, if necessary by queuing work to be 
scheduled later. Both engine and platform should not 
block for extended periods of time. 

In extreme situations, the volume of " trans ferOut » 
operations may overwhelm the buffering provided by a CI. 
25 In this situation, the CI can call "stop()» which will 
have the effect of preventing all further calls to op° 
"transferOut". A subsequent call to "start ()" will resume 
output, possibly rescheduling engine tasks that had to be 
halted as a result of the blockage. 

30 CI Class 

Construction 
CI : 

CI (TsTelename *name) ; 
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Constructs a new CI object. "name" is the telename 
of the engine which will use this CI . 

-CI : 

virtual -CI () 
5 Shuts down and destroys this CI. 

main ; 

virtual long mainO = 0; 

The main loop of a CI . This is called some time 
after construction. The CI should yield to the engine, 
10 e.g. with «wait()", during the execution of this function. 

Engine Operations 
transferln: 

TsStatus transferln (TsOctets *bagOfBits, 

TsDestinationList *destList, 

15 unsigned int rank, 

TsWay *wayBack, 
int timeAdjust) ; 

Transfers one or more transfer units into the engine. 



463 



EP 0 634 719 A2 



trangferFaUed: 

TsStatus transf erFailed (TsFailure failure, 

TsOctets *bagOfBits, 

5 TsDestinationList *destList, 
unsigned int rank, 

TsWay *wayBack, int 

time Ad just) ; 

Transfers one or more failed transfer units into the 
10 engine. 

transf erOut Failed . 

TsStatus transf erOut Failed (TsFailure failure, 

unsigned int groupld, 
TslntegerList 

15 *list) ; 

Identifies one or more transfer units which have 
failed a previous performance of op n "transf erOut" from 
this engine. 

transf erOut Complete ? 
20 TsStatus transferOutComplete (unsigned int groupld, 

unsigned int 

transferSN) ; 

Indicates that the transfer of a transfer group 
(argument "groupld") has completed. The storage 
25 associated with all the transfer units in this group can 
be reclaimed. 

Platform O perations 
transf erOut ; 

virtual TsStatus transferOut (TsOctets *bagOfBits, 

30 
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TsDestinationList *destList , 
unsigned int rank, 
TsWay *wayOut, 

unsigned int desiredDuration, 
5 unsigned int maximumDuration, 

unsigned int groupld) = 0 ; 



Transfer the transfer units in this transfer group to 
their respective destinations (argument "destList") . 

failTransfer; 

10 virtual TsStatus failTransfer (unsigned int groupld) 

= 0; 



Pail all the transfer units associated with the 
transfer group (argument "groupld") . 



make Reservation : 

15 virtual TsStatus makeReservation (unsigned int 

dur a t i on , TsRese rva t i on 

♦reservation) = 0 ; 



Request a new reservation (argument "reservation") 
with the specified duration (argument "duration"). 

20 resetRes ervation = 

virtual TsStatus resetReservation (TsReservation 

reservation, unsigned int duration) 

0; 



Reset the duration of reservation to the new duration 
25 (argument -duration"). A duration of zero has the effect 
of canceling the reservation. 



Task Operations 
wait : 
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void wait (long msec) 

Yields the current engine thread for "msec" 
milliseconds. The function will return when this thread 
is rescheduled. If argument "msec" is zero, the thread 
5 will be rescheduled as soon as the engine scheduling 
policy allows. If argument "msec" is -1 this call to 
"waitO" will not return until "satisfy ()» (see below) is 
called or a file descriptor specified with "waitfdO" 
become s ready . 

10 satisfy: 

void satisfy () ; 

Causes the CI thread to be rescheduled if the CI 
thread is blocked in a "waitO" call. 

waitfd: 

15 void waitfd (int fd, short mask); 

Specifies that subsequent "wait()» calls will return 
if the file descriptor "fd" becomes ready for either 
reading or writing as specified by "mask". "mask" is a 
bitmask constructed by OR-ing the values "POLLIN" and 
"POLLOUT" which select for the file descriptor being 
readable and writable respectively. A "mask" of zero has 
the meaning that this file descriptor should no longer 
affect the operation of "wait () " . 

waitresult! 
25 short waitresult (int fd) ; 

Returns a bitmask which can be used to test whether 
the file descriptor "fd" may have become ready during the 
previous "wait()« call. The result is a bitmask with the 
bits "POLLIN" and "POLLOUT" set if they were specified in 
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"waitfdO" and the file descriptor became ready for read 
or write respectively. 

Stop : 

void stop () ; 

5 Causes the engine to throttle all "transf erOut" op n s 

for this CI. No further transfers will be requested of 
this CI, which may cause Telescript agents executing op n 
"go" or "send" to block. The CI should only invoke this 
operation if the CI would loose data by queuing further 
10 transfers. 



start : 



void start () ; 

Informs the engine that it should no longer throttle 



op n s. 

30 15 L TELESCRIPT INTERFACE OBJECTS 

To enable communication with external systems, e.g. 
other Telescript engines or non-Telescript -based 
communicating systems, a Telescript engine must rely on 
35 communications services provided by a platform or 

20 operating system underlying the Telescript engine itself. 
To gain access to these services, the Telescript engine 
must support a mechanism to allow information to flow into 
and out of the Telescript abstraction. Specifically, to 
allow conversion between key Telescript objects and 
25 corresponding representations of these objects that are 
^ palatable to the underlying communication services. 

The Telescript Engine Interface Classes provide an 
abstract definition for a set of C++ classes that fulfill 
this need. The definition provided is abstract in that 
30 the C++ classes are not fully defined, but rather are 
described in terms of the Telescript engine's minimum 
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requirements on their functionality. Complete freedom is 
left to the implementor of these classes as to their 
internal mechanisms and their relationship with the 
underlying communication services. 

5 7 . 1 Interface Conventions 

An implementation of the Telescript Engine Interface 
Classes must adhere to a set of conventions regarding the 
use of data items which pass across the class interfaces. 
These conventions are expressed in terms of rules of 
10 ownership, wherein ownership is defined as the right to 
modify and the responsibility to destroy a given piece of 
data . 

Unless otherwise stated, an implementation of the 
Telescript Engine Interface Classes must adhere to the 
15 following interface conventions: 

• For all functions that accept reference or pointer 
arguments, ownership of the referenced or pointed to 
data passes from the caller to the object called, 
such that the object has the right to modify the data 

20 and the responsibility to destroy the data at the 

appropriate time. 

• For all functions that return reference or pointer 
values, ownership of the referenced or pointed to 
data is retained by the called object. However, the 

25 object guarantees that, until the next call to a 

function that can modify the object, the data 
referenced/pointed at will not change. 

• When destroyed, an object will destroy all data for 
which is has ownership. 

30 7 . 2 TsCharacter 

The "TsCharacter" type definition provides a limited 
C++ representation of the Telescript Character class, as 
defined in Appendix A of this disclosure. 
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An implementation of the "TsCharacter" type is 
required to be able to contain all ASCII characters. This 
is a minimum requirement. Preferably, an implementation 
of the "TsCharacter" type can contain all Unicode 
5 characters . 

10 

7.3 TsDestination 

The "TsDestination" class provides a C++ 
representation of the Telescript Destination class, as 
« defined in Section 4 of this Appendix. An implementation 

10 of the "TsDestination" class shall provide, at a minimum, 
the following functionality, 
class TsDestination 

{ 

public: 

TsDestination (TsTeleaddress * teleaddress, 
TsTelename * telename, 
TsOctets * data) ; 
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-TsTeleaddress () 



30 



const TsTeleaddress * getTeleaddress () const; 
20 const TsTelename * getTelename () const; 

^ const TsOctets * getData () const; 

}; 

Construction 

25 TsDestination (TsTeleaddress * teleaddress, 

TsTelename * telename, 
TsOctets * data) 

45 

Constructs a new "TsDestination" object, 
so teleaddrgg g 
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Either a pointer to a "TsTeleaddress" object that is 
to form the teleaddress value of the new "TsDestination" 
object, or the NULL pointer if the destination object is 
to contain no teleaddress value. 

5 telename 

Either a pointer to a "TsTelename" object that is to 
form the telename value of the new "TsDestination object, 
or the NULL pointer if the destination object is to 
contain no telename value. 

10 data 

Either a pointer to a "TsOctets- object that is to 
form the destination data value of the new -TsDestinat ion- 
object, or the NULL pointer if the destination object is 
to contain no destination data value. 

15 Destrucrh jp ^ 

-TsDestination ; 
-TsDestination () 

Destroys the "TsDestination" object. The 
"TsDestination" object and all data for which the object 
20 has ownership responsibility are destroyed. 

Data AcrpgH 

qetTel eaddreaa r 

const TsTeleaddress • getTeleaddress () const 

Returns either a pointer to the teleaddress value of 
25 the "TsDestination" object, or the NULL pointer if the 
destination object contains no teleaddress value. 

get Telename : 

const TsTelename * getTelename () const 
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Returns either a pointer to the telename value of the 
"TsDestination" object, or the NULL pointer if the 
destination object contains no telename value. 



10 



5 



getPata : 

const TsOctets * getData () const 



Returns either a pointer to the destination data 
value of the "TsDestination" object, or the NULL pointer 
if the destination object contains no destination data 
value . 



The "TsDestinationList" class provides a C++ 
representation of a Telescript class "List" as defined in 
Appendix A of this disclosure, constrained to contain 
objects of the class "Destination". An implementation of 
15 the "TsDestinationList" class shall provide, at a minimum, 
the following functionality. 



20 



10 7.4 TsDesti nat ionLi s t 
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class TsDestinationList 
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public; 

TsDestinationList () ; 
-TsDestinationList () ; 

const TsDestination * nextDestination () ; 
void reset () ; 

size_t destinationCount () const; 



40 



25 



void appendDestination (TsDestination * 



45 




50 
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Construction 

TsDestinationList • 
TsDestinationList ( ) 
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Constructs an empty "TsDestinationList " object. 

Destruction 

-TsDestination-Liat : 
-TsDestinationList ( ) 

5 Destroys a "TsDestinationList" object. The 

"TsDestinationList" object and all data for which the 
object has ownership responsibility are destroyed. 

Data Access 

appendPest ination : 
10 void appendDestination (TsDest ination * destination) 

Appends a single destination, in the form of a 
"TsDestination" object to the list of destinations 
contained within the "TsDestinationList" object. 

destination 

15 A pointer to a "TsDest ination" object conveying the 

destination to be appended to the list of destinations 
within the TsDestinationList object. 

nextDestination : 

const TsDestination * nextDestination () 

20 Returns either a pointer to a destination, in the 

form of a "TsDestination" object, or the NULL pointer. 
Over multiple invocations, the "nextDestination () ■ 
function returns the set of destinations contained within 
the "TsDestinationList" object in the order of their 

25 containment. Subsequent to return of the last destinatior 
and until the next invocation of the reset function, the 
"nextDestination () » function returns the NULL pointer. 

reset : 
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void reset { ) 

Causes Che next invocation of the "nextDestination ( ) " 
function to return the first destination contained within 
the TsDes t inat ionLis t n object. 

5 destinationCount : 

size_t destinationCount () const 

Returns the number of destinations currently- 
contained within the "TsDestinationList " object. 

20 7.5 TsExist inaConnect ionMeans 

10 The "TsExist ingConnect ionMeans" class provides a C++ 

representation of the Telescript " Exist ingConnect ionMeans" 
class, as defined in Section 3 of this appendix. An 
implementation of the "TsExist ingConnect ionMeans" class 
shall provide, at a minimum, the following functionality. 
15 class TsExist ingConnect ionMeans : public 

TsRese rvabl eMeans 

{ 

public: 

TsExist i ngConnec t i onMe ans 
35 20 (const TsReservation & reservation, 

TsOctets * connectionld) ; 
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-TsExist ingConnect ionMeans () ; 

const TsOctets * get Connectionld () const; 
}; 

25 Construction 

TsExist incr- Co nnect ionMeans : 

TsExistingConnectionMeans (const TsReservation & 
reservation, 

TsOctets * connectionld) 
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Constructs a new "TsExistingConnectionMeans" object. 



reservation 

A reference to a "TsReservation" object that is to 
form the reservation value of the "TsReservableMeans" 
5 super-class component of the new 
"TsExistingConnectionMeans" object . 

connect ionTH 

A pointer to a "TsOctets" object that is to form the 
connection identifier value of the new 
10 "TsExistingConnectionMeans" object. 

Pestniction 

-TsExistina-ConnectinnMA^nQ ■ 
-TsExistingConnectionMeans () 

Destroys the "TsExistingConnectionMeans- object. The 
15 "TsExistingConnectionMeans" object and all data for which 
the object has ownership responsibility are destroyed. 

Data Access 

cretCon nectionld 

const TsOctets * getConnectionld () const 



20 



Returns a pointer to the connection identifier value 
contained within the "TsExistingConnectionMeans" object. 



7 . 6 Ts Integer- 

The "Tslnteger" type definition provides a limited 
C++ representation of the Telescript class "Integer". 
25 An implementation of the "Tslnteger" type shall be 

capable of holding values in the range -2147483648 to 
+2147483647 inclusive. 
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1 - 7 TsIntegerList 

The "TsIntegerList" class provides a C++ 
representation of a Telescript class "List", as defined in 
Appendix A of this disclosure, constrained to contain 
5 objects of the class "Integer". An implementation of the 
"TsIntegerList " class shall provide, at a minimum, the 
following functionality, 
class TsIntegerList 

{ 

15 10 public: 

TsIntegerList (); 
-TsIntegerList () ; 

const Tslnteger * nextlnteger () ; 

20 

void reset ( ) ; 
15 size_t integerCount ( ) const ; 

25 void appendlnteger (Tslnteger integer) ; 

}; 

Construction 
30 TsIntegerList : 

2 0 TsIntegerList () 



35 
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Constructs a new "TsIntegerList" object. 

Subsequent to construction and until the first 
invocation of the "appendlnteger () " function, the newly 
created integer list object will be empty. 

25 Destruction 

-TsIntegerList: 
-TsIntegerList () 



Destroys a "TsIntegerList" object. The 
"TsIntegerList" object and all data for which the object 
so 30 has ownership responsibility are destroyed. 
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appendlnteaer : 

void appendlnteger (Tslnteger integer) 

Appends a single integer, in the form of a 
"Tslnteger" object, to the list of integers contained 
5 within the TsIntegerList object. 

integer 

An integer value to be appended to the list of 
integers within the "TsIntegerList" object. 

next Integer : 
10 const Tslnteger * next Integer () 



Returns either a pointer to an integer, in the form 
of a Tslnteger object, or the NULL pointer. Over multiple 
25 invocations, the " next Integer () " function returns the set 

of integers contained within the "TsIntegerList" object in 
15 the order of their containment. Subsequent to return of 
the last integer and until the next invocation of the 
reset function, the "nextlnteger () n function returns the 
NULL pointer. 



reset : 
20 void reset () 



Causes the next invocation of the "nextlnteger () » 
40 function to return the first integer contained within the 

"TsIntegerList" object . 



inteoerCounh ; 
25 size_t integerCount () const 



Returns the number of integers currently contained 
within the "TsIntegerList" object. 
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7^8 T^Means 

The "TsMeans" class provides a C++ representation of 
the Telescript class "Means" as defined in Appendix A of 
this disclosure. An implementation of the "TsMeans" shall 
5 provide, at a minimum, the following functionality, 
class TsMeans 

{ 

public: 

typedef enum 
10 { 

TsMeansType_PSTN = 0, 
TsMeansType_ExistingConnection = 1 
} Type; 
virtual -TsMeans () =0; 
15 Type type () const; 

protected: 
25 TsMeans (Type type) ; 

}; 
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Construction 
20 TsMeans : 

TsMeans (Type meansType) 

Constructs a new "TsMeans" object. 
meansTyp e 

An enumeration specifying the means type value of the 
25 new "TsMeans" object. 



Destruction 

-TsMeans : 
45 virtual -TsMeans () 

Destroys the "TsDestination" object. The 
30 "TsDestination" object and all data for which the object 
has ownership responsibility are destroyed. 
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Data Access 
type: 

Type type () const 

Returns the means type value of the "TsMeans" object. 

5 7 . 9 TsObi Soeci f ier 

The "TsObj Specifier" provides a C++ representation of 
a class of objects each of which denotes a protocol and 
distinguishes that protocol from other protocols. For 
example, a member of the class represented by 
.0 "TsObjSpecif ier" can be used to denote a specific way of 
providing security. An implementation of the 
"TsObjSpecif ier" class shall provide, at a minimum, the 
following functionality, 
class TsObjSpecif ier 
5 { 

public : 

TsObjSpecif ier (Tslnteger objld, 

TsOctets * namingAuthority) ; 
-TsObjSpecif ier () ; 
0 Tslnteger getObjld () const; 

const TsOctets * getNamingAuthority () const; 

}; 

Construction 

TsObi Specif ier : 
5 TsObjSpecif ier (Tslnteger objld, TsOctets * 

namingAuthority) 

Constructs a new TsObjSpecif ier object. 
obi Id 

An integer value that is to form the object 
0 identifier value of the new "TsObjSpecif ier " object. 
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naminaAuthor i t y 

Either a pointer to a "TsOctets" object that is to 
fo rm the naming authority value of the new 
"TsObjSpecifier" object; or the NULL pointer, if the new 
5 "Tsobj Specifier" object is to contain no naming authority 
value . 



Destruction 

-TsObi Specifier: 
-TsObj Specif ier ( ) 

10 Destroys the "TsObjSpecifier" object. The 

"TsObjSpecifier" object and all data for which the object 
has ownership responsibility are destroyed. 



Data Access 
25 qetOb-i Id : 

15 Tslnteger getobjld () const 



20 



Returns the object identifier value contained within 
the "TsObjSpecifier" object. 

QetNaminq-Authority* 

const TsOctets * getNamingAuthority () const 

Returns either a pointer to a "TsOctets" object 
conveying the naming authority value contained within the 
"TsObjSpecifier" object; or the NULL pointer, if the 
"TsObjSpecifier" object contains no naming authority 
value . 

25 7. 10 TsOctet 

The TsOctet type provides a C++ representation of the 
Telescript class "Octet" as defined in Appendix A of this 
disclosure . 
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The "TsOctet" type shall be defined as a C++ unsigned 

char. 

7 -H TsQctets 

The "TsOctets" class provides a C++ representation of 
5 the Telescript class "Octets" as defined in Appendix A of 
this disclosure. An implementation of the "TsOctets" 
class shall provide < at a minimum, the following 
functionality. 

class TsOctets 
10 { 

public: 

20 enum CopyOwnership { makeCopy, ownCopy, 

borrowCopy } ; TsOctets (size_t size); 

TsOctets (size_t size, const TsOctet * data, 
15 CopyOwnership ownership = makeCopy) ; 

25 -TsOctets ();const TsOctet * nextSeg (int & 

segSize) ; void reset () ; 

size_t size () const; 
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void appendSeg (size_t size, const TsOctet * 

20 data) ; 

}; 



Conatruct-inn 

TsOctets: 

TsOctets "size_t size, TsOctet * data, CopyOwnership 
40 25 ownership) 

Constructs a "TsOctets" object from a single array of 
"TsOctet" objects. 



size 



The number of octets to be contained within the new 
30 "TsOctets" object. 
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data 

A pointer to an array of octets, i.e., "TsOctet" 
objects, to be contained within the new "TsOctets" object. 
The number of elements in the array must be greater than 
5 or equal to the value of "size". 

Note: For the case where "size" is zero, a zero length 

array must be provided by the caller. 

ownership 

An enumeration specifying the method by which the 
.0 array of octets is to be incorporated into the new 
"TsOctets" object. The possible values are: 

"makeCopy" : the data within the octet array must be 

incorporated into the new "TsOctets" object 
by the construction of a separate physical 
5 copy. Subsequent to the construction, the 

caller retains complete ownership of the 
original octet array. 
When the ownership argument specified is 
"makeCopy", the octet array provided by the caller 
0 may be either statically, dynamically or 

automatically allocated. 

"ownCopy" : The data within the octet array can, at the 

implementation's discretion, be 
incorporated into the new "TsOctets" object 
directly, via the incorporation of the 
provided octet array itself. Subsequent to 
the construction, the caller relinquishes 
ownership of the provided octet array to 
the new "TsOctets" object. 

When the ownership argument specified is 
"ownCopy", the octet array provided by the caller 
must be dynamically allocated. 



481 



EP 0 634 719 A2 



"borrowCopy" : The data within the octet array can, at the 
implementation's discretion, be 
incorporated into the new "TsOctets" object 
directly, via the incorporation of the 
provided octet array itself. Subsequent to 
the construction of the "TsOctets" object 
and until its destruction, the caller loans 
the caller's ownership of the provided 
octet array to the new "TsOctets" object. 
For this duration, neither the caller nor 
the "TsOctets" object may modify or destroy 
the octet array. Upon destruction of the 
"TsOctets" object, complete ownership of 
the octet array passes back to the caller. 
15 When the ownership argument specified is 

"borrowCopy", the octet array provided by the caller 
can be either statically, dynamically or 
automatically allocated. 
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TsOctets : 

TsOctets (size_t eventualSize) ' 

Constructs an empty "TsOctets" object in preparation 
for the addition of data using the "appendSegO " function, 
which is described below. 

eventual Si?:? 

The maximum number of octets to eventually be 
contained with the new "TsOctets" object. 

Destruction 

-TsOctets- 
-TsOctets () 



482 



EP 0 634 719 A2 



Destroys the "TsOctets- object. The "TsOctets" 
object and all data for which the object has ownership 
responsibility are destroyed. 

Data Access 
5 appendSecr : 

void appendSeg (size_t size, 
TsOctet * data, 
CopyOwnership ownership) 

Appends an array of octets, i.e., "TsOctet" objects 
10 to the set of octets already existing within the 
"TsOctets" object. 

Nate: The effect of invoking this function upon a 

"TsOctets" object created by means of a 
constructor other than the "TsOctets", i.e., by 
15 means of argument "eventualSize" of the 

constructor function above, size "eventualSize" 
constructor is implementation defined. 
Additionally, the effect of appending more data 
than that declared in the "eventualSize" 
parameter of the constructor is also 
implementation defined. 



20 



size 

The number of octets to be appended to the "TsOctets" 
object. 

25 data 

A pointer to an array of octets, i.e. "TsOctet" 
objects, to be appended to the "TsOctets" object. The 
number of elements in the array must be greater than or 
equal to the value of "size". 
3 0 Note: For the case where "size" is zero, a zero length 

array must be provided by the caller. 
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ownership 

An enumeration specifying the method by which the 
array of octets is to be incorporated into the "TsOctets" 
object. The possible values and their corresponding 
meanings are the same as those described for the "TsOctets 
(size_t size, TsOctet * data, CopyOwnership ownership)" 
function. 

nextSea: 

const TsOctet * nextSeg (size_t & segSize) 



.0 



0 



Returns either an array of octets and a size value or 
the NULL pointer. Over multiple invocations, the 
"nextSeg" function returns a collection of octet array 
segments which together, in order of appearance, convey 
the array of octets contained within the "TsOctets" 
5 object. Subsequent to the return of the last such segment 
and until the next invocation of the "reset" function, the 
"nextSeg" function returns the NULL pointer and leaves the 
value of the "segSize" parameter unchanged. 
Note: The total number of segments returned and size 

of each individual segment are implementation 
dependent . 

segSize 

A reference to an unsigned integer value to be 
updated with the size of the segment being returned. 

reset : 

void reset () 

Causes the next invocation the "nextSeg" function to 
return the first segment of octets contained within the 
"TsOctets" object. 

size : 
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size_t size {) const 

Returns the total number of octets currently 
contained within the "TsOctets" object. 

7.12 TsPSTNMeans 
5 T he "TsPSTNMeans" class provides a C++ representation 

of the Telescript class n PSTNMeans n , as defined in Section 
3 of this appendix. An implementation of the 
"TsPSTNMeans" class shall provide, at a minimum, the 
following functionality. 
10 class TsPSTNMeans : public TsReservableMeans{ 

public : 

TsPSTNMeans (const TsReservation & reservation, 

TsTelenumber * telenumber) ; 
-TsPSTNMeans () ; 
15 TsTelenumber * getTelenumber () const; 

}; 

Construction 

TsPSTNMeans : 

TsPSTNMeans (const TsReservation & reservation, 
20 TsTelenumber * telenumber) 

Constructs a new "TsPSTNMeans" object. 

reservation 

A reference to a "TsReservation" object that is to 
form the reservation value of the "TsReservableMeans" 
25 super-class component of the new "TsPSTNMeans" object. 

telenumber 

A pointer to a "TsTelenumber" object that is to form 
the telenumber value of the new "TsPSTNMeans" object. 

Destruction 
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-TsPSTNMpan.g • 

-TsPSTNMeans ( ) 

Destroys the " TsPSTNMeans " object. The "TsPSTNMeans « 
object and all data for which the object has ownership 
5 responsibility are destroyed. 

Data Access 

aetTelenumhpr » 

const TsTelenumber * getTelenumber () const 

Returns a pointer to the telenumber value contained 
10 within the "TsPSTNMeans" object. 

7 . 13 TaReservableMftanfl 

The "TsReservableMeans" class provides a C++ 
representation of the Telescript class "ReservableMeans" , 
as defined in Section 3 of this appendix. An 
15 implementation of the "TsReservableMeans" class shall 
provide, at a minimum, the following functionality. 

class TsReservableMeans : public TsMeans 

{ 

protected: 

20 TsReservableMeans (TsMeans: : Type type, 

const TsReservation & reservation) ; 
virtual -TsReservableMeans () ; 
public : 

TsReservation & get Reservation () const* 

25 }; 

Construct! on 

TsRese rvableMeans ■ 

TsReservableMeans (TsMeans: : Type type, 

const TsReservation & reservation) 

30 Constructs a new "TsReservableMeans" object. 
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type 

An enumeration specifying the means type value of the 
"TsMeans" super-class component of the new 
" TsReservableMeans " object . 

5 reservation 

A reference to a "TsReservation" object conveying the 
reservation value to be contained within the new 
M TsReservableMeans n ob j ect . 

Destruction 
10 -TsReservable -Means ■ 

virtual -TsReservableMeans () 

Destroys the "TsReservableMeans- object. The 
"TsReservableMeans" object and all data for which the 
object has ownership responsibility are destroyed. 

15 Data Access 

getReaervation : 

const TsReservation & getReservation () const 

Returns a reference to the reservation value 
contained within the "TsReservableMeans" object. 



20 7.14 TsReservation 

The "TsReservation" class provides a C++ 
representation of the Telescript class "Reservation", as 
defined in Section 3 of this appendix. An implementation 
of the "TsReservation- class shall provide, at a minimum, 
25 the following functionality. 
45 class TsReservation 

{ 

public : 

TsReservation (Tslnteger id = 0) ; 
30 -TsReservation (); 
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Tslnteger id () const; 

}; 

Cons timet ion. 

TsReservation: 
5 TsReservation (Tslnteger id = 0) 

Constructs a new "TsReservation" object. 
id 

A "Tslnteger" that is to form the reservation 
identifier value of the new "TsReservation" object. 

10 Destruction 

-TsReservation : 
-TsReservation () 

Destroys the "TsReservation" object. The 
"TsReservation" object and all data for which the object 
15 has ownership responsibility are destroyed. 

Data Access 

Tslnteger id <) const 

Returns the reservation identifier value of the 
20 "TsReservation" object. 



2^15 TsString 

The TsString class provides a C++ representation of 
the Telescript class "String", as defined in Appendix A of 
45 this disclosure. An implementation of the "TsString" 

25 class shall provide, at a minimum, the following 
functional ity . 

Issue : This needs to be extended to support non-ASCII 
so character sets. 
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class TsString 

{ 

public : 

TsString (const TsCharacter * string) ; 
5 -TsString () ; 

const TsCharacter * getString () const; 
size_t size (} const; 

}; 

Construct ion 
10 TgStJTing: 

TsString (const TsCharacter * string) 

Constructs a new "TsString" object. 

string 

A pointer to a "TsCharacter" array, terminated by a 
15 null character, conveying the string of characters to be 
contained within the new "TsString" object - 

Destruction 

-TsString: 
-TsString () 

20 Destroys the "TsString" object. The "TsString" 

object and all data for which the object has ownership 
responsibility are destroyed. 

Data Access 

getString: 

25 const TsCharacter + getString () const 

Returns a pointer to the string of characters 
contained within the "TsString" object. 

size : 



489 



EP 0 634 719 A2 



size_t size () const 

Returns the number of characters currently contained 
within the "TsString" object. 

7 . 16 TsTeleaddress 
5 The "TsTeleaddress" class provides a C++ 

representation of the Telescript class "Teleaddress" , as 
defined in Appendix A of this disclosure. An 
implementation of the "TsTeleaddress" class shall provide, 
at a minimum, the following functionality. 
10 class TsTeleaddress 

{ 

public : 

TsTeleaddress (TsOctets * provider, 
TsString * location) ; 
15 -TsTeleaddress () ; 

const TsOctets * getProvider () const; 

const TsString * getLocation () const; 

const TsOctets * nextRoutingAdvice () ; 

void reset () ; 
20 int routingAdviceCount () const; 

void appendRoutingAdvice (TsOctets * advice) - 

}; 

Construction 

TsTeleaddress : 

25 TsTeleaddress (TsOctets * provider, TsString * 

location) 

Constructs a new "TsTeleaddress" object. 
Subsequent to construction, the list of routing 
advice elements contained within the newly created 
3 0 teleaddress object will be empty. 
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provider 

Either a pointer to a "TsOctets" object that is to 
form the provider value of the new "TsTeleaddress" object, 
or the NULL pointer if. the new teleaddress object is to 
5 contain no provider value . 

location 

Either a pointer to a "TsString" object that is to 
form the location value of the new "TsTeleaddress" object, 
or the NULL pointer if the new teleaddress object is to 
10 contain no location value. 

Destruction 

-TsTelead dress : 
-TsTeleaddress () 

25 Destroys the "TsTeleaddress" object. The 

15 "TsTeleaddress" object and all data for which the object 
has ownership responsibility are destroyed. 
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Data Access 

aPPendRoutina -Advi rr* - 

void appendRoutingAdvice (TsOctets * advice) 

Appends a single element of routing advice, in the 
form of a "TsOctets" object, to the list of routing advice 
contained within the "TsTeleaddress" object. 

advice 

A pointer to a "TsOctets" object conveying the 
25 routing advice element to be appended to the 
"TsTeleaddress" object's routing advice list. 



aetProvidpr- 

^ const TsOctets * getProvider () const 
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Returns either a pointer to the provider value of the 
"TsTeleaddress" object, or the NULL pointer if the 
"TsTeleaddress" object contains no provider value. 

aetLocation: 

const TsString * getLocation () const 

Returns either a pointer to the location value of the 
"TsTeleaddress" object, or the NULL pointer if the 
"TsTeleaddress" object contains no location value. 



nextRoutinaAdvice : 
20 10 const TsOctets * next Rout ingAdvice () 

Returns either a pointer to an element of routing 
advice, in the form of a "TsOctets" object, or the NULL 
25 pointer. Over multiple invocations, the 

"nextRoutingAdviceO " function returns the set of routing 
15 advice elements contained within the "TsTeleaddress" 
object in the order of their containment. 

Subsequent to return of the last routing advice 
element and until the next invocation of the reset 
function, the "nextRoutingAdviceO" function returns the 
20 NULL pointer. 



reset : 

void reset () 



Causes the next invocation of the 
"nextRoutingAdviceO" function to return the first element 
25 of routing advice contained within the "TsTeleaddress" 
45 object. 

routinaAd vice-Count ; 

size_t routingAdviceCount () const 

50 
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Returns the number of elements of routing advice 
currently contained within the "TsTeleaddress" object. 



7.17 TsTelename 

The "TsTelename" class provides a C++ representation 
5 of the Telescript class "Telename", as defined in Appendix 
A of this disclosure. An implementation of the 
"TsTelename" class shall provide, at a minimum, the 
following functionality, 
class TsTelename 
10 { 

public: 

TsTelename (TsOctets * authority, TsOctets * 
identity) ; -TsTelename () ; 

const TsOctets * getAuthority () const; 
15 const TsOctets * getldentity () const; 

}; 

Construction 

TsTelename : 

TsTelename (TsOctets * authority, TsOctets * 
20 identity) 



Constructs a new "TsTelename" object. 



authority 

A pointer to an octet string that is to form the 
authority value of the new "TsTelename" object. 

25 identity 

Either a pointer to an octet string that is to form 
the identity value of the new "TsTelename" object, or the 
NULL pointer if the "TsTelename" object is to contain no 
identity value. 
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Destruction 

-TsTelename : 
-TsTelename () 

Destroys the "TsTelename" object. The "TsTelename " 
5 object and all data for which the object has ownership 
responsibility are destroyed. 



Data Access 
15 get Authority : 

const TsOctets * getAuthority () const 



10 Returns a pointer to the authority value contained 

within the "TsTelename" object. 



get Identity: 

25 const TsOctets * getldentity () const 

Returns either a pointer to the identity value 
15 contained within the "TsTelename" object, or NULL if the 
"TsTelename" object contains no identity value. 



7 . 18 TsTe 1 enumbe r 

The " TsTe 1 enumbe r" class provides a C++ 
representation of the Telescript class "Telenumber" , as 
20 defined in Appendix A of this disclosure. An 

implementation of the "TsTelenuraber" class shall provide, 
at a minimum, the following functionality, 
class TsTelenuraber 

{ 

25 public: 

TsTelenumber (TsString * country, TsString * 
telephone, TsString * extension) ; 

-TsTelenumber () ; 
so const TsString * getCountry {) const; 

30 const TsString * getTelephone () const; 
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const TsString * getExtension () const; 

}; 

Const ruct ion 

TsTelenumber : 
5 TsTelenumber (TsString * country, TsString * 

telephone, TsString * extension) 

Constructs a new "TsTelenumber" object. 

country 

Either a pointer to a "TsString" object that is to 
10 form the country code value of new "TsTelenumber" object, 
or the NULL pointer if the "TsTelenumber" object is to 
contain no country code value. 

Note: The value contained within the provided 

"TsString" object is restricted to the set 
15 of numerical codes that CCITT assigns to 

countries or other geographical areas. 

telqphQiie 

Either a pointer to a "TsString" object that is to 
form the telephone number value of the new "TsTelenumber" 
20 object, or the NULL pointer if the "TsTelenumber" object 
is to contain no telephone number value. 
Note: The characters that form the value contained 

within the provided "TsString" object are 
restricted to the numerals ("0 n - n 9"), the hyphen 
25 character ("-") and the space character (" 

extension 

Either a pointer to a "TsString" object that is to 
form the extension number value of the new "TsTelenumber" 
object, or the NULL pointer if the "TsTelenumber" object 
30 is to contain no extension number value. 
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Note: The characters that form the value contained 

within the provided "TsString" object are 
restricted to the numerals ( "0" - " 9" ) , the hyphen 
character ("-■*) and the space character ( M "). 

5 Destruction 

-TsTelenumber : 
-TsTelenumber ( ) 

Destroys the "TsTelenumber" object. The 
"TsTelenumber" object and all data for which the object 
10 has ownership responsibility are destroyed. 

Data Access 

get Country; 

const TsString * getCountry () const 

Returns either a pointer to the country code value of 
15 the "TsTeleaddress" object, or the NULL pointer if the 
"TsTeleaddress" object contains no country code value. 

get Telephone: 

const TsString * getTelephone () const 



Returns either a pointer to the telephone number 
20 value of the "TsTeleaddress" object, or the NULL pointer 
if the "TsTeleaddress" object contains no telephone number 
40 value . 

cretExtension : 

const TsString * getExtension () const 
2 5 Returns either a pointer to the extension number 

value of the "TsTeleaddress" object, or the NULL pointer 
if the "TsTeleaddress" object contains no extension number 
50 value. 
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7 . 19 TsWay 

The "TsWay" class provides a C++ representation of 
the Telescript class "Way" , as defined in Appendix A of 
this disclosure- An implementation of the "TsWay" class 
5 shall provide, at a minimum, the following functionality. 

class TsWay 

{ 

public : 

TsWay (TsTelename * name, 
10 TsMeans * means, 

TsObjSpecif ier * secRegimeld) ; 
-TsWay () ; 



const TsTelename * get Name () const; * 
const TsMeans * getMeans () const; 
15 const TsObjSpecif ier * getSecRegimeld () const; 

25 } ; 

Construe t ion 
TsWay : 

TsWay (TsTelename * name, 
20 TsMeans * means, 

TsObjSpecif ier * secRegimeld) 



Constructs a new "TsWay" object. 
name 

Either a pointer to a "TsTelename" object that is to 
25 form the engine/region telename value of the new "TsWay" 
object, or the NULL pointer if the new "TsWay" object is 
to contain no engine/region telename. 



means 

Either a pointer to a "TsMeans" object that is to 
so 30 form the means value of the new "TsWay" object, or the 
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NULL pointer if the new "TsWay" object is to contain no 
means value. 

secReaimeld 

Either a pointer to a "TsObj Specifier" object that is 
5 to form the security regime identifier value of the new 
"TsWay" object, or the NULL pointer if the new "TsWay" 
object is to contain no security regime identifier value. 

Destruction 
~TsWav: 
10 -TsWay () 

Destroys the "TsWay" object. The "TsWay" object and 
all data for which the object has ownership responsibility 
are destroyed. 

Data Access 
15 get Name : 

const TsTelename * getName () const 

Returns either a pointer to the engine/region 
telename value contained within the "TsWay" object, or the 
NULL pointer if the "TsWay" object contains no 
20 engine/region telename. 

const TsMeans * getMeans () const 



Returns either a pointer to the means value contained 
^ within the TsWay object, or the NULL pointer if the 

25 "TsWay" object contains no means value. 



50 



get SecReaimeld ; 

const TsObjSpecifier * getSecRegimeld () const 
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Returns either a pointer to the security regime 
identifier value contained within the "TsWay" object or 
the NULL, pointer if the "TsWay" contains no security 
regime identifier value. 
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APPENDIX D 

Copyright © General Magic, Inc. 1993. All Rights 
Reserved. 

The following table of contents is to assist the 
5 reader in understanding the organization of and locating 
information within this appendix. 
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4 . 4 Shipping Box 

4 . 5 Traveled 

1 INTRODUCTION 

This appendix describes a mechanism for 
5 place-to-place transfer, broadly construed to include 
object interchange and purgatory. 

This appendix is organized in the manner of Appendix 
A of this disclosure. 

The place-to-place transfer mechanism necessitates 
10 several other changes and additions to the Instruction Set 
of Appendix A, which are described in the subsections 
below. 

1 . 1 Permit Changes 

Whether "go" or operation "send" succeeds or fails, 
15 allow operation "entering" to grant an agent an initial 
local permit more permissive than the one the agent 
requested. 

Provided operation "go" or operation "send" fails, 
allow operation "entering" to admit an agent while 

20 granting it an initial local permit less permissive than 
the one the agent requested. 

Add to class "Process" a read-only public instance 
attribute, "regional Permit " , which is the permit the 
current region grants a process. 

25 Replace the "terminate" operation of a place with a 

new, "changePermit" operation which replaces a process' 
local permit. The operation is performed at the request 
of either the place itself or a peer of the process in 
question. 

30 Add to class "Process" a system instance operation, 

"permitChanged", which the Engine requests whenever a 
place changes an occupant's local permit, e.g., as 
operation "entering" does above, or to eject the occupant 
with or without a grace period. 
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permifaChang pri • 

op ( ) Pe rmi t Changed | Ni 1 ,- 

Requested whenever the responder's local permit is 
changed e.g., by the place the responder is entering or 
5 occupies already, either to add capabilities or to remove 
them. If the operation's result is an exception, rather 
than a nil, the Engine throws the exception in the 
responder's thread of execution. 

The method for this operation that is native to class 
10 "Process" simply returns a nil. 

Add to class "Execution Exception- a subclass, 
"PermitChanged", the throwing of which signifies that the 
current process' local permit has been changed. 

PermitChangpH ■ 
15 interface (ExecutionException) = () ; 

Note: A process' ability to catch and recover from 

this exception, when the process' new local 
permit is severely restrictive, are limited by 
the rules of process termination. 

20 1.2 Other Chanq aa 

Provided operation "go" or operation "send" fails 
allow an agent to find one or more of its interchanged' 
objects missing, as described in the place-to-place 
transfer model. 

Allow the "go" or "send" operation to take an agent 
to its destination even if the operation fails, e g 
because the destination will not grant the agent the' 
permit the agent requested. Furthermore, operation 
"entering" is involved even in this case. 

Let the Engine request any feature, predefined or 
user-defined, not just a system feature. A user-defined 
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method for a feature requested by the Engine finds client 
and process to be nils, as if the feature were a system 
feature . 

Add to class "Process" a read-only public instance 
5 attribute, "authenticity" , which documents the degree of 
confidence the current region has in a process' purported 
authority. This attribute is defined in § 4.57 of 
Appendix A. 

To class "Process" add a read-only public instance 
10 attribute, "creationTime" , which is the time at which a 
process was created. 

Discard the "brand" attribute of a process. 
Not£: Instead a region can define a subclass of class 

"Permit" and supply an instance thereof as a 
15 process ' " regional Permit " attribute . 

2 TELESCRIPT CONCEPTS 

2.1 Place-to-place Transfer Model 

The Instruction Set realizes the "place-to-place 
transfer model" this section defines. 

20 2.1.1 Traveled Places 

A "traveled" place is one through which shipping 
boxes are transferred. 

Transfer 

The traveled places to which the Network entrusts a 
25 certain shipping box cooperate to "transfer" the box's 

contents from one place, the "origin" of the shipping box P 
to one or more places, "destinations" of the shipping box. 
A traveled place creates new shipping boxes whenever it 
must transfer the contents of a shipping box in different 
30 directions. 

The transfer of the contents of a shipping box from 
its origin to any one of its destinations proceeds in four 
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steps, the last two of which, i.e. transfer in and 
transfer out, can be repeated within a single transfer. 

Submission 

A transfer begins with a shipping box's "submission". 
5 The traveled place to which the shipping box is first 
transferred in as a consequence is its "source" . 

Delivery 

A transfer ends with a shipping box's "delivery". 
The places to which a submitted shipping box is to be 

10 delivered are its "destinations". 

A shipping box's delivery is either "normal" or 
"abnormal". In the first case, the shipping box's 
destinations are as specified at submission, and all 
critical parts of the shipping box's contents are present. 

15 In the second case, the Network may have prescribed 

alternative destinations for the shipping box, and some 
critical parts of the shipping box's contents may be 
absent. An exception explains the abnormality. 

Transfer In 

20 A shipping box is "transferred in" to a traveled 

place. The transfer in is a consequence of either the 
shipping box's submission from a place, traveled or 
otherwise, or the shipping box's transfer out from a 
traveled place, different from or the same as the traveled 

25 place to which the shipping box is transferred in. The 
place from which the shipping box comes is the shipping 
box's "previous hop". 

Transfer Ont- 

A shipping box is "transferred out" from a traveled 
30 place. The transfer out has as its consequence either the 
shipping box's transfer in to a traveled place, different 
from or the same as the traveled place from which the 
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shipping box is transferred out, or the shipping box's 
delivery to places, traveled or otherwise. The place or 
places to which the shipping box goes is the shipping 
box ' s " next hop " . 

5 2.1.2 Shipping Boxes 

A "shipping box" is one object that holds another, 
its "contents", and that can be used to transfer that 
object from place to place. 

Peek 

10 A traveled place can "peek" at the object that is a 

shipping box's contents, i.e., can get the object's 
attributes, subject to the limitation below. 

A shipping box gets an attribute of the shipping 
box's contents using a protected reference to the 

15 contents. If a user-defined method is involved, the 

method finds "client", "here", and "process" to be nils, 
as if the attribute were a system attribute. 
Additionally, peeking at an attribute disregards its 
prescribed passage, in every case returning a copy of the 

20 attribute, rather than the original. 

Poke 

A traveled place can "poke" at the object that is a 
shipping box's contents, i.e., can set the object's 
attributes, subject to the limitation below. A traveled 

25 place can do this, however, only if the traveled place is 
suitably privileged. 

A shipping box sets an attribute of the shipping 
box's contents using an unprotected reference to the 
contents. If a user-defined method is involved, the 

30 method finds "client", "here", and "process" to be nils, 
as if the attribute were a system attribute. 
Additionally, poking at an attribute disregards its 
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prescribed passage, in every case using a copy of the 
proposed attribute, rather than the original . 

The privileges alluded to above are assigned as 
follows. An engine place can set the 
5 "authenticationState" or "regionalPermit " attribute, even 
though the Instruction Set defines these attributes as 
read-only. Preemptive settings of the "regionalPermit" 
attribute can dictate the shipping box's abnormal 
delivery. 

10 Note ; A traveled place cannot request operations of a 

shipping box's contents. 

Rebox 

A traveled place can "rebox" a shipping box, which 
the traveled place does if the shipping box must be 
15 transferred in different directions. The Engine removes 
specified destination tickets from the shipping box, 
replaces them with nils, and reaf fixes them to a new 
shipping box identical in content to the existing one. 



20 



Redirect 

A traveled place can "redirect" a shipping box, which 
the traveled place does if an exception arises during its 
transfer. The Engine affixes the exception to the 
shipping box, removes any nils among the shipping box's 
destination tickets, and can substitute for each remaining 
25 destination ticket a single specified ticket. 

2 • 1 ■ 3 Opened Objects 

An "opened" object is one whose zero or more parts 
can be manipulated. 

Parts 

3 0 Each "part" of an object, opened or not, is an 

interchanged object whose digest is not a nil, A part of 
an opened object can be replaced with another object of 
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the part's class and digest without materially affecting 
the opened object. 

Presence 

Each part of an object, opened or not is either 
5 "present" or absent. The "absence" of a part, in general, 
limits the object's use, but makes the object's 
place-to-place transfer more efficient. If an object 
attempts to use a reference to a part of itself that is 
absent at the time, the Engine throws "Reference Void". 
10 Note: In typical practice, a part of the contents of a 

shipping box is present at the shipping box's 
submission and again at the shipping box's 
delivery, but is absent at some or all of the 
other steps in the shipping box's transfer, as a 
15 performance optimization. 

Criticality 

Each part of an object, opened or not, is either 
critical or non-critical. An object is designed to be 
used even in the absence of one or more of the object's 
20 "non-critical" parts, but not in the absence of any of the 
object's "critical" ones. 

Note: The absence of a critical part of an object 

prevents normal delivery of a shipping box 
containing that object, while the absence of a 
25 non-critical part does not, 

HQte: In typical practice, all parts of an object are 

critical everywhere. Occasionally, a part of an 
object is critical only while the object is in a 
certain place. 

30 2.1.4 Opened Shinning Boxes 

An "opened shipping box" is one whose parts can be 
manipulated. The parts of an opened shipping box are 
those of the shipping box's contents. 
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2.1.5 Part 9 Boxes 

A "parts box" is an opened object whose parts can be 
specified explicitly and arbitrarily. Parts boxes serve 
the following four purposes. 

5 Manipulating Parts 

The parts of an opened object are manipulated by 
means of parts boxes. This ensures that the parts are not 
directly accessible to the object doing the manipulation. 
The parts in a parts box, e.g., can be included in an 
10 opened object, and specified parts of an opened object can 
be copied or moved into a parts box. The parts themselves 
cannot be examined, even while in the parts box. 
NQ£e.: This protects the intellectual property 

represented by interchanged objects. 

15 Storing Parts 

A traveled place entrusted with opened shipping boxes 
can use a parts box as a repository for parts to be 
included in such shipping boxes. The parts box, a small 
database, serves as a resource in place-to-place transfer. 
20 No^e: This simplifies the implementation of traveled 

places. 

Taking Parts 

If a shipping box's contents include a parts box, the 
parts box's critical parts are specifically excluded from 
25 the shipping box's parts. Thus the traveled places 
involved in the shipping box's transfer can neither 
examine nor exclude those parts. The optimization that 
such exclusion would represent is not attempted. 
Nste: This enables agents that support place-to-place 

30 transfer to move interchanged objects between 

traveled places without the system as a whole 
attempting to avoid that movement by the 
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system's (in this case misguided) optimization 
efforts . 

Leaving Parts 

If a shipping box's contents include a parts box, the 
5 part box's non-critical parts are specifically included in 
the shipping box's. In this way, an agent can declare an 
interchanged object non-critical and thereafter take trips 
without that part of necessity accompanying the agent . By 
later removing the part from the parts box, the agent 
10 declares the part critical. Then, if the part is absent, 
either the Engine finds the part locally, or the Engine 
throws "Reference Void" when the agent uses the part, 
fiotje: This enables agents to visit places at which 

certain of their interchanged objects will not 
!5 be used without insisting that those objects 

nevertheless be present there . 

2 .1.6 The Use of Tickets 

Tickets define, as detailed below, the places through 
which a shipping box is transferred. Throughout this 
20 section, the "place attributes" are the "destinationName" , 
"destinationAddress", and "destinationClass" attributes. 
Other ticket attributes that are not mentioned 
specifically below are disregarded. 

Source 

25 A ticket is used to define a shipping box's source. 

The ticket's place attributes, which identify the source, 
are an assigned telename, an assigned teleaddress, and an 
assigned citation, respectively. The ticket's "way" 
attribute, if not a nil, dictates the way in which the 

30 source shall be reached if need be. 

Destination 
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A ticket is used to define each of a shipping box's 
destinations. The ticket's place attributes identify the 
destination in question. The ticket's "way" attribute, if 
not a nil f dictates the way in which that destination 
5 shall be reached. The "desiredWait " and "maximumWait » 
attributes give the quality of service to be provided the 
shipping box as it is transferred to that destination. 

Previous Hop 

A ticket is used to define a shipping box's previous 
10 hop. The ticket's attributes "destinationName" , 
"destinationAddress" and "destinationClass" , which 
identify the previous hop, are an assigned telename, an 
assigned teleaddress, and an assigned citation, 
respectively. The ticket's "way" attribute, if not a nil, 
15 defines the way in which the shipping box was transferred 
in from the previous hop. 

Next Hop 

A ticket is used to define a shipping box's next hop. 
The ticket's place attributes identify the next hop. The 
20 ticket's "way" attribute, if not a nil, dictates the way 
in which the next hop shall be reached. 

2.1.7 The Engine's Rol * 

Traveled places are properly viewed as facilitating, 
rather than controlling, the transfer of shipping boxes 
25 and their eventual delivery to their destinations. The 
Engine itself is instrumental in this process as follows. 

Transfer Tn 

Whenever a traveled place transfers in a shipping 
box, the Engine has already determined whether that 
3 0 shipping box is an opened one or not. In typical 
practice, the Engine makes this determination 
consistently, not on a box-by-box basis. Thus some 
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traveled places, in general, are entrusted with the 
interchange of parts of the contents of shipping boxes, 
while others are not. 

Transfer Out 

5 Whenever a traveled place transfers out a shipping 

box, "A", the Engine does the following. First, the 
Engine reboxes "A", moving to a new shipping box, "B", the 
tickets to any destinations to which the Engine can 
deliver shipping boxes. The Engine moves tickets to "B", 
10 however, only if the transfer out is one allowing 

delivery. Second, the Engine reboxes "A" again, moving 
all remaining tickets to another new shipping box, "C". 
Third, the Engine asynchronously transfers "C" and 
attempts to deliver "B" . 

15 Expiration 

Whenever a traveled place allows any destination 
tickets of a shipping box, "A n , to expire, the Engine does 
the following. Such a ticket "expires" when its maximum 
duration is reached. First, the Engine reboxes "A n , 

20 moving the expired tickets to a new shipping box, "B" . 

Second, the Engine redirects "B" to a place chosen by the 
Engine, recording "Ticket Expired" as the cause of the 
abnormality. Third, the Engine transfers out "B n to a 
place chosen by the Engine, as if the traveled place had 

25 done so. 

Discard 

Whenever a traveled place discards a shipping box, 
"A", to which any destination tickets remain affixed, and 
so as to provoke the finalization of "A", the Engine does 
30 the following. First, the Engine reboxes "A", moving all 
destination tickets to a new shipping box, n B". Second, 
the Engine destroys "A" . Third, the Engine asynchronously 
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transfers out »B« to a place of the Engine's own choosing, 
as if the traveled place had done so. 

2-- 1 • 8 The Engi ne's Rnle in Rout- i rig 

The Engine limits the routes along which a shipping 
5 box is transferred by selecting the shipping box's second 
hop, constraining the shipping box's second- to- last hop, 
and, furthermore, restricting the shipping box's first hop 
in any sequence of hops within a region. 



10 



First Regional Hon 

The Engines of a region cooperate to ensure that a 
shipping box entering the region is transferred in at an 
engine place before the shipping box is either transferred 
in at another traveled place in the region or delivered 
within the region. 

15 Second Hop 

The Engine selects as follows a shipping box's second 
hop, i.e., the traveled place at which the shipping box is 
first transferred in -- from the shipping box's source. 
The second hop is either the shipping box's 
20 submission place, if that is a traveled place, or a 

superplace of the submission place, otherwise. If several 
superplaces are traveled places, the one enclosing none of 
the others is selected. 

!22£S: Thus "submission" can be visualized as causing a 

25 shipping box to fall through its origin and 

successive superplaces until the shipping box 
reaches a traveled place. 

Second- to- last: Hap 

The Engine constrains as follows a shipping box's 
30 second-to-last hop, i.e., the traveled place from which 
the shipping box is last transferred out -- to all of the 
shipping box's destinations. 



512 



EP 0 634 719 A2 



The second-to-last hop is either a destination itself 
or one of its superplaces, this being so for each of the 
shipping box's destinations individually. 

Note: Thus "delivery" can be visualized as causing a 

5 shipping box to rise through successive 

subplaces until the shipping box reaches one 
qualifying as each destination of the shipping 
box. 

Given the second- to- last hop, if several places 
10 qualify as one of the shipping box's destinations, the 
Engine tries to deliver the shipping box to one of them, 
approaching them in the order defined by section 2.5.4 of 
Appendix A. 

Given the second-to-last hop, if either no places 
15 qualify as one of the shipping box's destinations or none 
of them accepts delivery of the shipping box, the Engine 
transfers out the shipping box to a place of the Engine's 
own choosing. 

Non -delivery 

20 An Engine treats the ultimate undeliverability of a 

shipping box as a system error, which the Engine handles 
in accordance with the OAM policy in force. 
Note: An Engine can provide a place of last resort, 

"Purgatory", for otherwise undeliverable 
25 shipping boxes. Such a place can severely limit 

an occupant's local permit. 

2.1.9 Implementing Go 

The method for "go" native to class "Agent" 
implements the operation as follows using a shipping box 
30 whose contents are the agent and the objects the agent 
owns . 

Submission 
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The Engine creates and submits a shipping box 
containing the agent after validating the agent's request 
for the operation. Thus the shipping box's first hop, 
i.e., its origin, is the place the agent occupies when the 
5 agent requests the operation. 

Delivery 

The Engine delivers a shipping box by completing the 
operation. Thus the shipping box's last hop, i.e., its 
sole destination, is the place the agent occupies when the 

10 agent completes the operation. 

The operation either succeeds, if both the shipping 
box does not record an exception and only non- critical 
parts of the shipping box's contents are absent, or fails, 
otherwise. If the operation fails, the operation throws 

15 either the exception the shipping box records, if the 

shipping box records one, or an exception of the Engine's 
choosing, otherwise . 

2.1.10 Impleme nting 5pnH 

The method for operation "send" native to class 

20 "Agent" implements that operation in the same way as 
operation "go" is implemented, with two differences. 
First, the shipping box has as many destinations as there 
are clones to be transferred. Second, the contents of the 
shipping box are a representative clone of the agent 

25 requesting the operation. The "identity" attribute of the 
clone's assigned telename is a nil at submission, but is 
set distinctively as each clone is delivered. 

1 TELE SCR IPT CLASS OVERVTKWg 

PUce-to-placP Transfer Group 
3 0 Object (Referenced) 

• £arts_Bo2£_ (Opened) 

• Shipping Box ( Unmoved ) 
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Opened Shipping Box (Opened) 

Opened 
Traveled 

3.1.1 Opened 
5 Operations 

clearParts 
examineParts 
excludeParts 
aetClassea 
10 oetDiaests 
getNumber 
20 includeParts 

An "opened" object is one whose parts can be 
manipulated . 

15 An opened object's native operations reveal the 

number (operation "getNumber" ) , classes (operation 
"getClasses") , and digests (operation n getDigests") of 
parts satisfying specified criteria; include new parts 
(operation "includeParts") ; exclude existing parts 
20 (operation "excludeParts " ) ; exclude all existing parts 

satisfying a specified criterion (operation "clearParts"); 
and arrange for the inspection of specified parts 
(operation "examineParts") . 



25 



30 



35 



40 



3.1.2 Opened Shipping Box 

25 A* 1 "opened shipping box" is one whose parts can be 

manipulated. 

45 3.1.? Parts Box 

Operations 

includeParts 

30 A "parts box" is an object whose parts can be both 

specified and manipulated. 



so 
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A parts box's native operation includes new parts 
(operation "includeParts" ) . 

3 Shipping Bnv 
Attributes 
10 5 destinations 

exception 
source 
time 
Operations 
10 peek 

poke 
rebox 
redirect 



15 



20 



30 



35 



45 



50 



A "shipping box" is an object that can be transferred 
25 15 between places. 

A shipping box's native attributes are the time the 
shipping box was submitted (attribute "time"), a ticket to 
the shipping box's source (attribute "source"), tickets to 
the shipping box's destinations (attribute 
20 "destinations") , and any exception encountered in 

transferring the shipping box (attribute "exception") . 

A shipping box's native operations get (operation 
"peek") or set (operation "poke") a specified attribute of 
the shipping box's contents, redirect the shipping box in 
25 case of an exception (operation "redirect"), and rebox the 
40 shipping box to permit several next hops (operation 

"rebox") . 



3.1.5 Traveled 
Operations 
30 trans ferOut 

transferredTn 



55 
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A "traveled" object is a place that can transfer 
5 shipping boxes . 

A traveled place's native operations transfer out a 
shipping box (operation "transf erOut 11 ) and act upon a 
5 shipping box's transfer in (operation "transf erredln" ) . 

4 TELESCRIPT CLASS DETAILS 

15 4 . 1 Opened 

Opened 

Class 

20 10 Opened : 

sealed abstract interface ( ) = (...); 

Public I nstance Operations 

25 

£l£ax£&£&£: 

unprotected op (isCritical: Boolean | Nil ) ; 

30 15 Removes from the responder and discards all of the 

responder's present parts that satisfy the criterion that 
the boolean (argument "isCritical") prescribes. See 
operation "getClasses" below. 

^x^njnepa^-ts: 

op ( of Class: Class ; 

digests: protected Set [Object]) 
PartsBox|Nil; 

Leaves in the responder and returns the present parts 
whose class (argument "of Class" ) and digests (argument 
25 "digests") are specified. The operation returns either a 
parts box comprising the parts, if there are any, or a 
nil, otherwise. 

excludeParts : 



20 

40 
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unprotected op (of Class: Class; 

digests: protected Set [Object]) 
PartsBoxjNil; 

Excludes from the responder and returns the present 
5 parts whose class (argument "of Class") and digests 

(argument "digests") are specified. The operation returns 
either a parts box comprising the parts, if there are any, 
or a nil, otherwise. 

oetClasses ■ 

10 op (isPresent, isCritical: Boolean j Nil) 

protected Set [Class] ; 

Returns the classes of the parts of the responder 
that satisfy the criteria -- defined below -- that the 
booleans (arguments "isPresent" and "isCritical") 
15 prescribe. 

The first criterion, defined by the first boolean, is 
that the part is either present, if the boolean is true; 
absent, if it is false; or either, if the argument is a' 
nil. The second criterion, defined by the second boolean 
20 1S that the part is either critical, if the boolean is 
true; non-critical, if it is f a i se . or either, if the 
argument is a nil. 

get Digest 

op (of Class: Class; isPresent, isCritical: 
25 Boolean | Nil) 

protected Set [Object] ; 

Returns the digests of the parts of the responder 
that are of the specified class (argument "ofClass") and 
that satisfy the criteria - see operation "getClasses" 
30 above - that the booleans (argument "isPresent" and 
"isCritical") prescribe. 
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getNumber : 

op (isPresent, isCritical: Boolean j Nil) Integer; 



Returns the number of parts of the responder that 
satisfy the criteria see operation "getClasses" above - 
5 -that the booleans ("isPresent" and "isCritical") 
prescribe . 

includeParts ; 

unprotected op (parts : protected PartsBox) ; 

Includes in the responder the parts of the parts box 
10 (argument "parts") that match, in class and digest, parts 
of the responder. The operation first excludes from the 
responder and discards any matching parts that are present 
there already * 




Class 



20 



Qpened ShippinqBoy - 

sealed interface (ShippingBox, Opened) = () ; 




Class 



25 



PartsBox: 

sealed interface (Object, Opened) = (...); 
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Construction 

initialize: 
unprotected op ( 

criticalParts , noncriticalParts : Set 
5 [Interchanged] (Nil) ; 

Makes the two sets of interchanged objects the 
responder' s critical (argument "criticalParts") and 
non-critical (argument "noncriticalParts") parts, all 
present initially. if a nil is present instead of a set, 
10 however, the set is presumed cleared. 

Public Inst ance Operations 
"includeParts" _■ 

unprotected op (parts: protected PartsBox) ; 

Includes in the responder the parts of the parts box 
15 (argument "parts"). Each part is considered present in 
the responder; each part is considered critical in the 
responder iff the part is so considered in the parts box. 
The operation first excludes from the responder and 
discards any matching parts that are present there 
20 already. 



4.4 Shipping Bnv 

Object (Referenced) 

• Shipping flmr (Unmoved) 

Class 

25 ShippinoBoy - 

sealed interface (Object, Unmoved) « (...); 

Cons t rue t i on 

initial i w • 
unprotected op () 
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throws FeatureUnavailable; 

Throws an exception ("FeatureUnavailable") . 
Note: A shipping box is created by means of operation 

"go" or "send", not using operation "new". 

5 Public Instance Attributes 
destinations : 

readonly protected List [Ticket | Nil] ; 

The tickets that define the responder's destinations, 
and zero or more nils, which replace tickets moved to 
10 other shipping boxes using operation "rebox" . 

readonly TripException | Nil ; 

Either the trip exception encountered in the course 
of transferring the responder, if indeed a trip exception 
15 was encountered, or a nil, otherwise. 

source : 

readonly protected Ticket; 

The ticket that defines the responder's source. 
time : 

20 readonly Time; 

The time at which the responder was submitted. 

Public Instance Operations 
peek : 

op (identifier: Identifier!) copied Object 
2 5 throws CopyUna vail able, FeatureUnavailable; 
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Returns the attribute of the responder's contents 
that the identifier (argument "identifier") denotes. 

An exception is thrown if the identifier denotes no 
attribute of the responder's contents that is accessible 
5 to the requester ("FeatureUnavailable") or a copy of the 
attribute is unavailable < "CopyUnavailable" ) . 

poke : 

unprotected op (identifier: Identifier! ; 
attribute: copied Object) 
10 throws Argument Invalid, AttributeReadOnly, 

FeatureUnavailable ; 

Makes the object (argument "attribute") the attribute 
of the responder's contents that the identifier (argument 
"identifier") denotes. The operation first discards the 
15 attribute if it exists. 

An exception is thrown if the object violates the 
attribute's constraint ( "Argument Invalid" ) , the attribute 
is read-only ( "AttributeReadOnly" > , or the identifier 
denotes no attribute of the responder's contents that is 
20 accessible to the requester ("FeatureUnavailable"). 

rebox : 

unprotected op (tickets: protected Set [Integer]) 

ShippingBox 
throws Positionlnvalid; 

Creates and returns a new shipping box whose contents 
are the same as the responder's, and moves to the new 
shipping box the tickets at the specified positions 
("tickets") in the responder's "destinations" attribute, 
replacing them with nils. 

An exception is thrown if an asserted position is 
invalid as such ("Positionlnvalid") . 



25 
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redirect : 

unprotected op (exception: TripException; 
newDestination: copied Ticket (Nil); 

Excludes from the responder's "destinations" 
5 attribute each nil item, replaces each item that remains 
with the ticket (argument "newDestination") iff there is 
one, and makes the exception (argument "exception") the 
responder' s "exception" attribute . 

Adaptations 
10 copy 

Throws Copy Unavailable. 

finalize 

Reboxes the responder as defined by the Model. 

4 . 5 Traveled 
15 Traveled 

Class 

Traveled; 

abstract interface () = (...); 

Private Instance Operations 
20 transferOut : 

unprotected op (shippingBox: unprotected ShippingBox 
suggestedNextHop : protected 
Ticket | Nil ; 
canDeliver: Boolean) ; 

25 Transfers out the shipping box (argument 

"shippingBox") to the place either defined by the ticket 
(argument "suggestedNextHop"), if not a nil, or selected 
by the Engine, otherwise. Even if the ticket is present, 
the ticket suggests, rather than demands, that the next 
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hop be the place that the ticket defines. The boolean 
(argument "canDeliver" ) indicates whether the Engine is 
free to deliver the shipping box if the Engine is able to 
do so. 

5 System Instance Operations 
transf erredln : 

abstract unprotected op (shippingBox: unprotected 
Shipp ingBox ; 

previousHop: protected Ticket); 

0 Requested as the shipping box (argument 

"shippingBox") is transferred in from the place defined by 
the ticket (argument "previousHop") . 



The computer program in Appendix G was compiled and 
linked, in one embodiment, using the UNIX operating system 

15 IRIX 4.0.5, the compiler, and the linker that are provided 
with a workstation such as the Iris Indigo® computer 
system available from Silicon Graphics of Mountain View, 
California. In a second embodiment, the computer program 
in Appendix G was compiled using the MPW C++ compiler, and 

20 was linked using the MPW linker, both of which are 
available from Apple Computer, Inc. of Cupertino, 
California and which can be used on an Apple Macintosh® 
computer, which is also available from Apple Computer, 
Inc. The particular computer language and the computer 

25 system used are not an essential aspect of this invention. 
In view of this disclosure, those skilled in the art can 
implement the invention using a different computer 
language and/or a different computer system. 



Claims 



A method for implementing remote programming in a computer network comprising the steps of: 

defining a plurality of object-oriented classes including an agent class and a place class; 
forming instructions for a computer process, said instructions including said object-oriented 

classes, subclasses of said object-ori nted classes, and a go operation; and 
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interpreting said instructions on a processor in said computer network wherein, in response 
to said go operation, an agent process is transported to a place process and further wh rein said ag nt 
process is a memb r f said agent class and said place process is a member of said place class. 

2. The method for implementing remote programming in a computer network as in Claim 1 further comprising 
forming said go operation within said agent process. 

3. The method for implementing remote programming in a computer network as in Claim 1 further compris- 
ing: 

defining a class of class objects; 

forming a class object, wherein said class object (i) is a member of said class of class objects, 
and (ii) defines a first class which is a subclass of a selected one of said object-oriented classes; and 

forming an object, said object being a member of said first class; 

wherein said agent process owns said object; and transportation of said agent proc- 
ess to said place process comprises transporting said object and said class object to said place process. 

4. A method for implementing remote programming in a computer network comprising the steps of: 

defining a plurality of object-oriented classes including an agent class and a place class; 

forming instructions for a computer process including said object-oriented classes, sub- 
classes of said object-oriented classes, and a send operation; and 

interpreting said instructions on a processor in said computer network wherein, in response 
to said send operation, a clone of an agent process is transported to a place process and further wherein 
said clone and said agent process are each a member of said agent class and said place process is a 
member of said place class. 

5. The method for implementing remote programming in a computer network as in Claim 4 further comprising 
forming said send operation within said agent process. 

6. The method for implementing remote programming in a computer network as In Claim 1 , 2, 4 or 5 f urth r 
comprising forming a subplace of said place wherein said subplace is a member of said place class and 
said place is a superplace of said subplace. 

7. The method for implementing remote programming in a computer network as in any one of Claims 1,2 
or 4 to 6 further comprising designating said agent process as an owner of an object. 

8. The method for implementing remote programming in a computer network as in Claim 7 wherein trans- 
portation of said clone comprises transporting a copy of said object to said place process. 

9. The method for implementing remote programming in a computer network as in Claim 7 or 8 further com- 
prising forming within said object a digest 

1 0. The method for implementing remote programming in a computer network as in Claim 9 further comprising 
interchanging for said first-mentioned object a second object at said place process wherein said second 
object has a second digest equivalent to said first-mentioned digest and further wherein said first object 
is not transported to said place process. 

11. The method for implementing remote programming in a computer network as in Claim 8 or 9 when ap- 
pended to claim 4, 5 or 6 further comprising interchanging for said copy a second object, which is different 
from said first-mentioned object, at said place process wherein said second object has a second digest 
equivalent to said first-mentioned digest and further wherein said copy is not transported to said place 
process. 

12. The method for implementing remote programming in a computer network as in any one of Claims 1 to 
11 further comprising sp cifying said place process by a ticket means. 

13. The method for implementing remote programming in a computer network as in Claim 12 further com- 
prising forming said ticket means within said agent process. 

14. The method for implementing remote programming in a computer network as in Claim 12 or 13 further 
comprising forming within said ticket means an address of said place process. 
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15. The method for implementing remote programming in a computer network as in Claim 14 wherein said 
address is a t leaddress 

1 6- The method for implementing remote programming in a computer network as in any one of Claims 12 to 
15 further comprising forming within said ticket means a name of said place process. 

17. The method for implementing remote programming in a computer network as in Claim 16 wherein said 
name is a telename. 

18. The method for implementing remote programming in a computer network as in Claim 4 further wherein, 
in response to said send operation, a second clone of said agent process is transported to a second place 
process wherein said second clone is a member of said agent class and is distinct from said first- 
mentioned clone and further wherein said second place process is a member of said place class. 

19. The method for implementing remote programming in a computer network as in Claim 18 further com- 
prising: 

determining that transportation of said first clone to said first place process and of said sec- 
ond clone to said second place process requires transportation of said first and second clones to a single 
computer of a plurality of computers of said computer network; 

transporting said first clone to said single computer; and 

forming, in a single computer, said second clone from said first clone. 



20. The method for implementing remote programming in a computer network as in Claim 19 further com- 
prising: 

transporting said first clone from said single computer to said first-mentioned place process; 
transporting said second clone from said single computer to said second place process. 

21. A method for interprocess communication in a computer comprising the steps of: 

defining a plurality of object-oriented classes including an agent class; 
30 forming instructions for a computer process including said object-oriented classes, sub- 

classes of said object-oriented classes, and a meet operation; and 

interpreting said instructions on a processor in said computer network wherein, in response 
to said meet operation, a meeting place process provides a first agent process access to a second agent 
process and provides said second agent process access to said first agent process and further wherein 
35 said first and second agent processes are members of said agent class. 

22. The method for interprocess communication in a computer as in Claim 21 wherein said meeting place proc- 
ess is a member of a place class in said plurality of object-oriented classes and further wherein said first 
and second agent processes occupy said meeting place process. 

40 

23. The method for interprocess communication in a computer as in Claim 22 further comprising forming a 
second place process wherein: 

said second place process is a member of said place class; 
said second place process is a sub place of said meeting place process; and 
45 said meeting place is a superplace of said second place. 

24. A method for controlling movement of processes in a computer network, said method comprising the steps 
of: 

defining a plurality of object-oriented classes including an agent class, a place class, and a 

ticket class; 

forming a plurality of place processes in said computer network wherein each of said plur- 
ality of place process is a member of said place class; 

forming an agent process wherein said agent process is a member of said agent class and 
occupies a first place process in said plurality of place processes; and 
^ forming a tick t wherein said ticket is a member of said ticket class and defines a trip in- 

volving the mov ment of said ag nt process from said first place process to a second place process in 
said plurality of place processes. 
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25. A method for limiting capabilities of process s in a computer network, said method comprising: 

defining a plurality of object-oriented classes including a process class and a p rmit class; 
forming a process wherein said process is a member of said process class; and 
forming a permit wherein said permit is a member of said permit class and specifies one or 
5 more capabilities of said process. 

26. The method as in Claim 25 further comprising: 

defining within said process class a go operation; and 

specifying within said permit whether said process is capable of performing said go opera- 

10 tion. 

27. The method as in Claim 25 or 26 further comprising: 

defining within said process class a send operation; and 

specifying within said permit whether said process is capable of performing said send 

15 operation. 

28. The method as in Claim 25, 26 or 27 further comprising: 

defining within said process class a charge operation; and 

specifying within said permit whether said process is capable of performing said charge op- 
eration. 

20 

29. The method as in any one of Claims 25 to 28 further comprising: 

defining within said process class a terminate operation; and 

specifying within said permit whether said process is capable of performing said terminate 

operation. 

30. The method as in any one of Claims 25 to 29 further comprising specifying within said permit whether 
said process is capable of creating a second process, different from said first-mentioned process, wherein 
said second process is a member of said process class. 

30 31. The method as in any one of Claims 25 to 30 further comprising: 
defining an object-oriented place class; and 

specifying within said permit whether said process is capable to creating members of said 

place class. 

35 32. The method as in any one of Claims 25 to 31 further comprising specifying within said permit wheth r 
said process is restarted upon failure of said process. 

33. The method as in any one of Claims 25 to 32 further comprising specifying within said permit an amount 
of processing that is allotted to said process. 

40 

34. The method as in any one of Claims 25 to 33 further comprising specifying within said permit a time at 
which said process is terminated. 



25 



35. The method as in any one of Claims 25 to 34 further comprising: 
defining within said process class a restrict operation; 

forming instructions for a computer process, said instructions including said classes, sub- 
classes and of said classes, and said restrict operation; 

interpreting said instructions on a processor in said computer network wherein, in response 
to said restrict operation, a second permit, which is different from said first-mentioned permit, is formed 
and further wherein said second permit is a member of said permit class and specifies a group of one or 
more capabilities of said one or more capabilities of said process; and 

restricting said process to said group of one or more capabilities specified by said second 

permit 

36. In a computer, a method of interpreting processes of various versions of an instruction set said method 
55 comprising: 

defining a plurality of object-oriented classes including a class of classes and a class of cit- 
ations; 
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forming one or more class objects wherein said class objects are members of said class of 

classes; 

forming within a first of said class objects a citation wherein said citation specifies said first 
class object and specifies which of said class objects are backward compatible with said first class object. 

5 

37. In a computer network having a plurality of computers, a communication process comprising: 

providing a plurality of place processes within said computer network wherein each place 
process is a locale in one of said computers for zero or more agent processes; 

specifying, by a ticket means, a trip for an agent process to a destination place process in 
io said plurality of place processes; and 

transporting, in response to a send operation within said agent process, a clone of said agent 
process to said destination place process. 

38, In a computer network having a plurality of computers, the communication process as in Claim 37 further 
1S comprising specifying, by a second ticket means, a second trip, which is different from said first- 
mentioned trip, for said agent process to a second destination place process in said plurality of place proc- 
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39. In a computer network having a plurality of computers, the communication process as in Claim 37 further 
comprising: 

determining that said first-mentioned clone, in taking said first trip, and a second clone, in 
taking said second trip, are both to be transported to a single computer of said computers; 
moving to said single computer said first clone; and 
forming within said single computer said second clone from said first clone. 

25 40- I n a computer network having a plurality of computers, the communication process as in Claim 39 further 
comprising transporting said first clone to said first-mentioned destination place process. 

41. In a computer network having a plurality of computers, the communication process as in Claim 39 further 
comprising transporting said second clone to said second destination place process. 

30 

42, In a computer network having a plurality of computers, the communication process as in Claim 37f urth r 
comprising transporting, in response to a go operation within said agent process, said agent process to 
said destination place process specified by said ticket means. 

35 43- In a computer network having a plurality of computers, the communication process as in Claim 37 further 
comprising specifying said destination place process by a name within said ticket means. 

44. In a computer network having a plurality of computers, the communication process as in Claim 37 further 
comprising specifying said destination place process by an address within said ticket means. 

40 

45, In a computer network having a plurality of computers, the communication process as in Claim 37f urther 
comprising specifying, within said ticket means, said destination place process by a citation of a class f 
which said destination place process is a member. 
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46. In a computer network having a plurality of computers, the communication process as in Claim 37f urther 
comprising specifying, within said ticket means, said destination place process by any combination of an 
address of said destination place process, a name of said destination place process, and a citation of a 
class of which said destination place process is a member. 

47. In a computer network having a plurality of computers, the communication process as in Claim 37 f urth r 
50 comprising specifying, within said ticket means, a transportation means wherein said transportation 

means specifies a type of intercomputer communications means by which said clone is transported. 

48. In a computer network having a plurality of computers, the communication process as in Claim 37 further 
comprising controlling, with a destination permit contained in said ticket m ans, a deadline for said agent 

55 process at said destination place process. 

49. In a computer network having a plurality of computers, the communication process as in Claim 37furth r 
comprising controlling, with a destination permit contained in said ticket means, operations that said agent 
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process is allowed to p rform at said destination place process. 

50. In a computer network having a plurality of computers, the communication process as in Claim 37f urther 
comprising controlling, with a destination permit contained in said ticket means, resources that said agent 
process is allowed to consume at said destination place process. 

51. In a computer network having a plurality of computers, the communication process as in Claim 37f urther 
comprising specifying, with a destination permit contained in said ticket means, a priority for said agent 
process at said destination place process relative to other processes at said destination place process. 

52. In a computer network having a plurality of computers, the communication process as in Claim 37f urther 
comprising controlling, via a permit means, a capability that a process is allowed to have. 

53. In a computer network having a plurality of computers, the communication process as in Claim 52wherein 
said capability comprises a priority for said process relative to other processes. 

54. In a computer network having a plurality of computers, the communication process as in Claim 37 wherein 
said agent process owns an object. 

55. In a computer network having a plurality of computers, the communication process as in Claim 53 wherein 
20 said step of transporting a clone of said agent process comprises transporting a copy of said object 

56. In a computer network having a plurality of computers, the communication process as in Claim 55 further 
comprising interchanging for said copy a second object at said destination place process wherein said 
second object has a digest equivalent to said first-mentioned digest and further wherein said copy is not 

25 transported to said destination place process. 

57. In a computer network having a plurality of computers, the communication process as in Claim 54 further 
comprising the step using an interchanged object for said object at said destination place process thereby 
eliminating the need to transport said object to said destination place process. 

30 

58. In a computer network having a plurality of computers, the communication process as in Claim 37 wherein 
said transporting step further comprises a step of entering said destination place process. 

59. In a computer network having a plurality of computers, the communication process as in Claim 37 wherein 
said transporting step further comprises a step of exiting said source place process. 

60. In a computer network having a plurality of computers, the communication process as in Claim 37 wherein 
said destination place process is a meeting place process and said meeting place arranges a meeting 
between a requestor agent process and a petitioned agent process. 

40 61. In a computer, a communication process comprising: 

providing a first agent process and a second agent process; 

specifying a meeting between said first and second agent processes by a petition means; 

and 

arranging said meeting between said first and second agent processes as defined by said 

45 petition. 

62. In a computer, the communication process as in Claim 61 further comprising forming said petition means 
within said first agent process. 

63. In a computer, the communication process as in Claim 61 or 62 wherein said step of specifying a meeting 
comprises specifying within said petition means said second agent process. 

64. In a computer, the communication process as in Claim 63 wherein said step of specifying said second 
agent process comprises specifying, within said petition means, said s cond ag nt by a name. 
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65. In a computer, the communicati n process as in Claim 63, wherein said step of specifying said s cond 
agent process comprises specifying, within said petition means, a class of which said second agent proc- 
ess is a member. 
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66. In a computer, the communication process as in Claim 63 wherein said step of specifying said second 
agent process comprises specifying, within said pettti n means, a citation of a class of which said second 
agent process is a member. 

67. In a computer, the communication process as in Claim 61 wherein said step of specifying a meeting com- 
prises specifying, within said petition means, a maximum time period for arranging said meeting. 

68. In a computer, the communication process as in Claim 61 wherein said step of arranging said meeting 
comprises providing to said first agent process a reference to said second agent process. 

69. In a computer, the communication process as in Claim 68 wherein said step of arranging said meeting 
further comprises providing to said second agent process a reference to said first agent process. 

70. In a computer, the communication process as in Claim 81 further comprising causing, in response to an 
instruction within said first agent process, performance of an operation within said second agent process. 

71 . In a computer, the communication process as in Claim 70 wherein said first or second agent process owns 
an object 

72. In a computer, the communication process as in Claim 71 further comprising providing to said second or 
to said first agent process respectively a reference to said object, or a reference to a copy of said object. 

73. In a computer, the communication process as in Claim 72 wherein said reference is a protected reference. 

74. In a computer network having a plurality of computers, a communication system comprising: 

an agent means having a ticket means and a send operation; and 

a plurality of place means wherein each place means is operable in one of said plurality of 

computers; 

wherein said agent means is at a first place means in said plurality of place means; 
said ticket means specifies a trip to said agent means to a destination place means 
in said plurality of place means; and 

said send operation transports a clone of said agent means to said destination place 

means. 

75. In a computer network having a plurality of computers, the communication system as in Claim 74 wherein 
said agent means further comprises a second ticket means, different from said first-mentioned ticket 
means, that specifies a second trip to a second destination place means for said agent means. 

76. In a computer network having a plurality of computers, the communication system as in Claim 74 wherein 
performance of said send operation transports a second clone of said agent means to said second des- 
tination place means. 

77. In a computer network having a plurality of computers, the communication system as in Claim 76 wherein: 

said first-mentioned trip and said second trip both include transportation to a single com- 
puter in said plurality of computer and 

further wherein, in transporting said first-mentioned clone to said first-mentioned destina- 
tion place means and said second clone to said second destination place means, performance of said 
send operation: 

(a) transports said first clone to said single computer and 

(b) forms said second clone from said first clone within said single computer. 

78. In a computer network having a plurality of computers, the communication system as in Claim 74 wherein 
said agent means further comprises a go operation wherein said go operation transports said agent 
means to a third destination place means specified by a third ticket means. 

79. In a comput r network having a plurality of computers, th communicati n system as in Claim 74 wherein 
said ticket means further comprises a name which identifies said destination place means. 

80. In a computer network having a plurality of computers, th communication system as in Claim 74 wh rein 
said ticket means further comprises an address for said d stination place means. 
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81. In a computer n twork having a plurality of computers, the communication process as in Claim 44 or th 
system as in Claim 80 wherein said address is a t I address. 

82. In a computer network having a plurality of computers, the communication system as in Claim 74 wherein 
said ticket means further comprises a citation means which specifies a class of which said destination 
place means is a member. 

83. In a computer network having a plurality of computers, the communication system as in Claim 74 wherein 
said ticket means further comprises any combination selecting from the group consisting of an address 
of said destination place means, a name of said destination place means, and a citation means which 
specifies a class of which said destination place means is a member. 

84. In a computer network having a plurality of computers, the communication system as in Claim 74 or proc- 
ess of Claim 37 wherein said ticket means further comprises means for specif ying a maximum ti me period 
for said trip. 

85. In a computer network having a plurality of computers, the communication system as in Claim 74 or a 
process of Claim 37 wherein said ticket means further comprises means for specifying a desired time 
period for said trip. 

86. In a computer network having a plurality of computers, the communication system as in Claim 74 wherein 
said ticket means further comprises a way means for specifying a type of intercomputer communications 
means by which said trip is to be accomplished. 

87. In a computer network having a plurality of computers, the communication system as in Claim 74 wherein 
said ticket means further comprises a permit means for controlling a deadline for said agent means at 
said destination place means. 

88. In a computer network having a plurality of computers, the communication system as in Claim 74 wherein 
said ticket means further comprises a permit means for controlling operations that said agent means is 
allowed to perform at said destination place means. 

89. In a computer network having a plurality of computers, the communication system as in Claim 74 wherein 
said ticket means further comprises a permit means for controlling resources that said agent means is 
allowed to consume at said destination place means. 

90. In a computer network having a plurality of computers, the communication system as in Claim 74 wherein 
said ticket means further comprises a permit means for specifying a priority for said agent means at said 
destination place means relative to other agent means at said destination place means. 

91. In a computer network having a plurality of computers, the communication system as in Claim 74 furth r 
comprising a permit means for controlling a capability that an agent means is allowed to have. 

92. In a computer network having a plurality of computers, the communication system as in Claim 91 or the 
process as in Claim 52 wherein said permit means is a native permit 

93. In a computer network having a plurality of computers, the communication system as in Claim 91 or the 
process as in Claim 52 wherein said permit means is a local permit. 

94. In a computer network having a plurality of computers, the communication system as in Claim 91 or the 
process as in Claim 52 wherein said permit means is a temporary permit 

95. In a computer network having a plurality of computers, the communication system as in Claim 91 or the 
process as in Claim 52 wherein said capability comprises resources that said agent means of Claim 91 
or said process of Claim 52 respectively can consum . 

96. In a computer network having a plurality of computers, the communication system as in Claim 91 or the 
process as in Claim 52 wherein said capability comprises ad adlin after which the ag ntm ans of Claim 
91 r th process of Claim 52 respectively cannot proceed. 
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97. In a computer network having a plurality of computers, the communication system as in Claim 91 further 
comprising other agent means wherein said capability comprises a priority for said ag nt m ans relative 
to said other agent means. 

98. In a computer network having a plurality of computers, the communication system as in Claim 91 or the 
process of Claim 52 wherein said capability comprises permission for said agent means or said process 
respectively to perform selected operations. 

99. In a computer network having a plurality of computers, the communication system as in Claim 74 wherein 
said agent means owns an object. 

100. In a computer network having a plurality of computers, the communication system as in Claim 99 or the 
process of Claim 54 wherein said object has a digest. 

1 01 . In a computer network having a plurality of computers, the communication system as in Claim 1 00 wherein 
a copy of said object is transported with said clone by performance of said send operation. 

1 02. in a computer network having a plurality of computers, the communication system as in Claim 1 01 wherein 
a second object at said destination place means is interchanged for said copy; and 

further wherein said second object has a digest equivalent to said first-mentioned digest, 
thereby obviating transportation of said copy to said destination place means. 

1 03. In a computer network having a plurality of computers, the communication system as in Claim 1 01 wherein 
said send operation uses an interchanged object for said copy at said destination place means thereby 
eliminating the need to transport said copy of said object to said destination place means. 

104. In a computer network having a plurality of computers, the communication system as in Claim 74 wherein 
said place means further comprises means for entering said place means. 

105. In a computer network having a plurality of computers, the communication system as in Claim 74 wherein 
said place means further comprises means for exiting said place means. 

106. In a computer network having a plurality of computers, the communication system as in Claim 74 wherein 
said place means further comprises meeting place means wherein said meeting place means arranges 
a meeting between a requestor agent means and a responder agent means. 

107. In a computer, a communication system comprising: 

meeting place means having a meet operation wherein said meeting place is a locale for a 
plurality of agent means; 

a petition means; 

a first agent means in said plurality of agent means; and 

a second agent means in said plurality of agent means wherein; 

said first and second agent means can meet with any of said plurality of agent means; 

said petition means specifies a meeting between said first and second agent means; 

and 

in response to said meet operation, said meeting place means arranges said meeting. 

108. In a computer, the communication system as claimed in Claim 107 formed by a process according to any 
one of claims 61 to 73. 

109. In a computer, the communication system as in Claim 79 or 1 08 or the communication process as in Claim 
43 or 64 wherein said name is a telename. 

110. In a computer, the communication system as in Claim 107 further wherein said meet operation provides 
to said first agent means a reference to said second agent 

111. In a computer, th communication system as in Claim 110 further wherein said meet op ration provides 
to said second agent means a referenc to said first agent m ans. 

112. In a computer, th communication syst m as in Claim 107 further wherein said first agent means can 
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cause performance of an operation within said second agent means. 

113. In a computer, the communication system as in Claim 112 wherein at least on of said first agent means 
or said second agent means owns an agent 

114. In a computer, the communication system as in Claim 11 3 further wherein said first or second agent means 
can provide to said second or first agent means respectively a reference to said object or to a copy of 
said object. 

115. In a computer, the communication system as in Claim 114 wherein said reference is a protected referenc . 



116. In a computer network having one or more computers, a method for transferring data from a first engin 
process to a second engine process, said method comprising the steps of: 

(a) providing means for executing one or more agent processes wherein said executing means com- 
prises said first and second engine processes and further wherein each said agent process comprises 

15 instructions from a computer instruction set and has an execution state; 

(b) providing within said computer instruction set a go instruction wherein said go instruction is con- 
tained within a first agent process executing within said first engine process and further wherein per- 
formance of said go instruction causes: 

(i) suspension of execution of said first agent process by said first engine process; 
20 (ii) representation of said first agent process such that said execution state of said first agent proc- 

ess is preserved; 

(iii) transfer of said representation of said first agent process from said first engine process to said 
second engine process; and 

(iv) resumption of execution of said first agent process by said second engine process; 

25 (c) causing execution of said agent process by said first engine process, thereby causing performance 

of said go instruction. 

117. The method of Claim 116 wherein said computer instruction set is object-oriented. 

30 118. The method of Claim 117 wherein said plurality of agent processes are objects of said object-oriented 
computer instruction set. 

119. The method of Claim 116 further comprising the step of adding data to said first agent process prior to 
causing performance of said go instruction; 

35 wherein said representation of said first agent process includes said data; and 

further wherein transfer of said representation of said first agent process to said second en- 
gine process includes transfer of said data. 

120. The method of Claim 116 wherein said first agent process comprises data representing a message to be 
^ transported from said first engine process to said second engine process; and 

further wherein transfer of said first agent process resulting from execution of said go in- 
struction causes transfer of said data from said first engine process to said second engine process. 
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121. The method of Claim 116 wherein said first engine process executes on a first computer and said second 
engine process executes on a second computer wherein said first and second computers are part of said 
computer network. 

122. A method for transferring data from a first engine process to one or more engine processes, said method 
comprising the steps of: 

(a) providing means for executing a plurality of agent processes which comprise instructions from a 
computer instruction set wherein said agent process execution means comprises said first and one or 
more engine processes and further wherein each said agent process has an execution state; 

(b) providing within said computer instruction set a send instruction wherein said send instruction is 
contained within a first agent process in said plurality of agent processes and further wh rein, execution 
of said send instruction, includes the steps of: 

(i) forming one or more copies of said first agent process wherein said copies preserve and include 
said execution state of said first agent process; 

(ii) transferring each of said copies of said first agent process from said first engine process to a 
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respective one of said one or more ngine processes; and 

(iii) ffectuating execution of each f said copies of said first agent process by said respectiv one 
of said one or more engine processes so as to simulate the resumed ex cution of said first agent 
process. 

123. The method of Claim 122 wherein, upon a condition wherein two or more of said copies of said first agent 
process are to be transferred from said first engine process to a single second engine process, the transfer 
of said two or more copies of said first agent process comprises the steps of: 

transferring to said second engine process a single copy of said first agent process; and 
forming within said second engine process from said single copy said two or more copies 
of said first agent process. 

124. A method of transferring data from a first agent process which is executing within a computer system to 
a second agent process which is executing within said computer system wherein said first and second 
agent processes are occupants of a place process, said method comprising the steps of: 

causing, in response to a meet instruction issued by said first agent process, execution of 
a procedure by said second agent process wherein said procedure is a portion of said second agent proc- 
ess and comprises a collection of computer instructions contained within said second agent computer 
process; and 

providing to said first agent process, in response to a second instruction which is issued by 
said second agent process and which is part of said procedure, means for accessing said second agent 
process. 

125. The method of Claim 124 wherein said step of causing execution of a procedure by said second agent 
process comprises: 

causing, in response to said meet instruction issued by said first agent process, execution 
of a second procedure by said place process wherein execution of said second procedure by said place 
process issues an instruction which causes said second agent process to execute said first-mentioned 
procedure. 

126. The method of Claim 124 wherein said means for accessing said second agent process is provided to 
said first agent process by said place process. 

1 27. The method of Claim 1 26 wherein, at approxi mately the time said place process provides to said first agent 
process said means for accessing said second agent process, said place process provides to said second 
agent process means for accessing said first agent process. 

128. A method for transferring a first computer process from a first computer system to a second computer 
system, said first computer system comprising a first CPU and a first memory and said second computer 
system comprising a second CPU and a second memory, said method comprising: 

initiating execution of said first computer process within said first CPU wherein said com- 
puter process has an execution state; 

suspending execution of said first computer process within said first CPU; 

representing said first computer process as data in said first memory wherein said data in- 
cludes said execution state of said first computer process at the time execution of said first computer proc- 
ess is suspended; 

transferring said data from said first memory to said second memory; 

forming a second computer process on said second computer system from said data wherein 
said second computer process has said state of execution represented in said data; and 

causing execution of said second computer process, thereby effectively simulating resump- 
tion of execution of said first computer process within said second CPU. 
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